public note-to-self: an important part of the speedups that should be possible with PEX native lockfiles is skipping the building of the “repository pex”

--pex-repository

, and directly consuming the lockfile to build each subset of the resolve. i haven’t followed up on this because there is a lot in flight, but doing that is likely something that would be worth getting into 2.11.x as a key benefit to the switch

I'm interested in taking a look at this. If you have any breadcrumbs, please leave them 🤓

@hundreds-father-404: i know you’re recovering (hope you feel better), but when you’re up to explaining this one that would be great

this would be great to implement. I have lots of doctors appointments / therapy still the next two weeks, so indeed your help @bitter-ability-32190 would be really helpful I think the main trick is

pex_from_targets.py

. That's where all the repository pex shenanigans happen.

pex.py

is too general for that. My advice is to temporarily assume that all lockfiles are Pex format - how would we implement this? Now, still assume Pex format, but consider

[python].use_entire_lockfile

or whatever it is. Finally, consider requirements.txt-style lockfiles which need to still do the repository Pex thing. It's gonna be pretty ugly code to figure this out, but I think worth it!

Little PoC showing us sidestepping all non-veng pexs for deps https://github.com/thejcannon/pants/tree/lockspeedy

exciting! will definitely look this afternoon.

New pr being posted soon

awesome! thanks.