(Wasn’t sure if this belonged here on the pip GitHub. Happy to relocate)
I’m playing around with translating the pip report into a Pex lockfile, and I think so far the only missing piece here would be that a VCS requirement is missing the archive_info.
Would that be surfaceable? It’d be the digest of the downloaded-and-zipped requirement here.
The result of this working would be monumental for locking (especially paired with pip’s recent PEP 658 support )
The direct url data structure spec says there is no archive_info for VCS urls. That is because there is never an archive involved when pip deals with such urls.
If you want to “lock” such URL you need to provide an immutable commit reference.
Ah there’s a spec! So a PEP seemingly would be the way to get this in the proper channels?
I agree using immutable references are the way to truly transcend time across installs, but not everyone uses them and forcing them to do so is certainly an uphill climb (especially considering you could inherit one of these from your dependencies)
There are merits to hashing the not-guaranteed-to-be-immutable VCS requirement:
It may very well be immutable. I mean, if no one mutates it, then, well, it hasn’t mutated. Why give a bad UX to the user?
IF it was locked AND it mutated that’s a huge red flag. Your build isn’t reproducible anymore. Do not pass Go. Do not collect $200.
So, I’d be willing to throw the PEP out there so long as people are willing to read/discuss it.