Closed huonw closed 1 month ago
It's likely the case the only answer here is to fail fast when exporting a lock with either VCS or Local project requirements since the resulting --hash
ed requirements file will be unusable by any known tool.
I could imagine it's not implausible that someone takes the output of export
and munges it to remove the --hash
es (opting-in to losing the security advantages of the hashes, of course), and thus making this an error would break them. That might be a use case PEX regards too weird/extreme, though.
Ok, since I'm confident the current scheme is broken for anyone with VCS or local project requirements (the hash can never match the hash of the pinned artifact currently emitted) I feel safe I don't break anyone using --hash
further by switching fro X==Y
to the VCS requirement or local project path as appropriate. If there are folks like you hypothezise that munge the file, they'll at least now have the proper list of requirements left. Towards that end, I think I'll add an export format choice to omit hashes. This seems like a real-world reasonablish use case.
It seems like exporting a lockfile with a VCS requirement can sometimes use a
<name>==<version>
specifier in the exportedrequirements.txt
, not<name> @ <url>
as specified in the lockfile. This results in attempting to install different artifacts, with different hashes, to the ones PEX originally selected & hashed.test.lock
:requirements.txt
:Output of
pip install
:This example uses the tagged commit of a version, but the same thing applies to using a non-tagged commit, e.g.
pex @ git+https://github.com/pex-tool/pex@36dd2374569b5f3fbef54918e6ba3bd1ff852b61
(36dd2374569b5f3fbef54918e6ba3bd1ff852b61)The same thing applies to
pex3 lock export-subset
too.