-
-
Notifications
You must be signed in to change notification settings - Fork 292
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support resolving using a Pex lock file. #1583
Comments
N.B.: This is also required to support the final phase of #1556 which requires Pex to do the hashing and hash-checking of loose source project requirements (local and VCS projects). |
These bits of metadata are needed to consume the lock without needing to resolve through Pip. Work towards pex-tool#1583.
These bits of metadata are needed to consume the lock without needing to resolve through Pip. Work towards pex-tool#1583.
These bits of metadata are needed to consume the lock without needing to resolve through Pip. Work towards #1583.
We can't _consume_ PEX lockfiles until pex-tool/pex#1583, but the generation is now stable. Part 1 of #13964. Why land this? It lets us finish up the PEX generation code. For example, a follow-up PR can wire up `[python-repos]`. We can frontload some PEX-related work without blocking on pex-tool/pex#1583. Note that we generate in PEX's JSON format and do _not_ call `pex3 lock export`, as the export is lossy and does not attempt to handle things like environment markers. [ci skip-rust]
This is the 1st half of resolving from a lock. The second half is fetching the urls, building any fetched sdists and then installing all the resulting wheels. Work towards pex-tool#1583
This is the 1st half of resolving from a lock. The second half is fetching the urls, building any fetched sdists and then installing all the resulting wheels. Work towards pex-tool#1583
This is the 1st half of resolving from a lock. The second half is fetching the urls, building any fetched sdists and then installing all the resulting wheels. Work towards #1583
Perf is decent. Cold:
Where cold standard breaks down as:
And cold lock breaks down as:
Warm:
Where warm standard breaks down as:
And warm lock breaks down as:
The only surprising result is the cold lock case taking 1 second longer to do the wheel installs. That's likely a bug to suss out. |
This was added in pex-tool#152 to fix pex-tool#101 but has since been lost to vendored Pip taking over for ~all network requests. Pex will be fetching artifacts recorded in its lockfiles now; so it's time to restore this. Work towards pex-tool#1583.
Work towards pex-tool#1583.
For the local case of lock create and then later resolve, it will be good to retain the (primary) artifacts downloaded for the local interpreter when creating the lock used to lock in order to save downloading those artifacts again when later resolving from the lock. Work towards pex-tool#1583.
For the local case of lock create and then later resolve, it will be good to retain the (primary) artifacts downloaded for the local interpreter when creating the lock used to lock in order to save downloading those artifacts again when later resolving from the lock. Work towards pex-tool#1583.
The Pex CLI can now resolve from a lock file created via `pex3 lock create` when creating PEX files. Closes pex-tool#1583
For the local case of lock create and then later resolve, it will be good to retain the (primary) artifacts downloaded for the local interpreter when creating the lock used to lock in order to save downloading those artifacts again when later resolving from the lock. Work towards #1583.
Nice! What is the granularity of "cold" vs "warm" here? Is it on a distribution-by-distribution basis, such that a resolve might be partially warm? |
The cold is The code though has |
Instead of exporting the lock file to
requirements.txt
format and letting Pip do the resolve, record theRequires-Dist
metadata in the lock so that Pex can calculate the resolve (subset) using the logic it already has for--pex-repository
and then parallel-download all required dists. The backend to this can then be the current Pip build and install phase (BuildAndInstallRequest
).The text was updated successfully, but these errors were encountered: