Reduces warm lock time from 13.5 minutes (where hash component took 12-13 minutes) to 1.3 minutes! (of which the hash component takes 30s)

@ncoghlan would you mind giving this a once over for security concerns? This is a sizeable performance gain

@jtratner@vphilippon I see that pip-tools has brought in some local repository hashing upstream, is this going to be impacted by that at all if we bring it over?

seehttps://github.com/jazzband/pip-tools/blob/master/piptools/repositories/local.py#L67-L78 --

defget_hashes(self,ireq):key=key_from_req(ireq.req)existing_pin=self.existing_pins.get(key)ifexisting_pinandireq_satisfied_by_existing_pin(ireq,existing_pin):hashes=existing_pin.options.get('hashes', {})hexdigests=hashes.get(FAVORITE_HASH)ifhexdigests:return {':'.join([FAVORITE_HASH,hexdigest])forhexdigestinhexdigests                }returnself.repository.get_hashes(ireq)

Ok let’s get the test fixes finalized (possibly contingent upon integration test failures getting sorted) and then merged and then we can get this and everything else current and tested properly

+1 from me

• on the server side, as@jratner notes,pipenv is already trusting that to provide correct artifacts, trusting it for hashes makes sense too. The PEP 503 URL scheme + artifact hashes means that collisions really shouldn't happen (if you wanted to be particularly paranoid, you may decide to reject the use of md5 hashes for caching purposes)
• locally, you can mess with a build by messing with the lookup cache, but that's already possible by messing directly with pip's caches. Build machines really need to be trusted and secured environments if you're concerned about that kind of attack vector.

plz rebase :D

I merged in master since it was doable automatically although I see now you want to clean this up first so I'll just leave it