How hard would it be to support merging a pex file...
# pex
h
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.
e
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
a
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: https://github.com/pantsbuild/pants/pull/9101
re: the PR i just linked: i'm not sure i understand the need for the separate
create_bash_script_execution_request()
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
unzip
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): https://github.com/pantsbuild/pants/pull/8940