How hard would it be to support merging a pex file...
# pex
How hard would it be to support merging a pex file containing only requirements with one containing no requirements? This is an important special case, for example when running
./pants binary
- right now we have to re-resolve all the 3rdparty requirements even if only 1stparty code changed.
One thing to think about as well is why make a requirements only PEX in the 1st place, why not just run a resolve and store the resulting ResolvedDistributions. Then you can build a binary straight up in 1 go with a PEXBuilder.
👍 1
If its because your using a CLI and not the API, perhaps write a small cli that uses the resolver API.
This is seeming like a better and better idea. So, a rule that uses the downloaded pex binary to generate a pex from a python file (a resource target in the Pants repo) that supports a small CLI that runs the resolver and plops out its solution in pinned requirements and wheel chroots to the EPR chroot for collection as output digests.
🚢 1
potentially relevant work might be this draft PR that adds a few utilities to make it easier to use checked-in bash scripts in EPRs:
re: the PR i just linked: i'm not sure i understand the need for the separate
method, it could be deleted
a rule that unzips a file from a pex is something i've wanted for ipex in v2 as well (it currently just runs
and expects it to be on the PATH to extract PEX-INFO from a requirements pex, which is how it implements caching the resolve, via EPR caching):