https://pantsbuild.org/ logo
Join Slack
Powered by
Is there a way to build a pex for commands (such a...
# general
f
Is there a way to build a pex for commands (such as 
pants test
or 
pants run
) without trying to bundle 3rd party code? I know you can use PEX_INHERIT_PATH=prefer when running the pex but I'm not sure how to tell Pants to not even try to resolve the 3rd party deps to put them in the pex to begin with.
e
No. Clearly the 3rd party code is needed though; so what's your plan / problem / scheme?
Is this roughly "Pants / Pex are too slow, just please use my pre-built venv with all deps for all code built in? - trust me, this is not hermetic but I have carefully arranged this venv to exist on all machines."
f
This is "all my 3rd party libs are actually provided by RPMs, not Pip, but I lied to Pants and made up fake python packages for all of them so I could turn on `unowned_dependency_behavior = error`"
Maybe I could make a fake resolve that excludes my fake deps, (don't think this will work) and then pass 
--unowned-depdency-behavior=ignore
when running 
pants test
.
I'm aware this is all kinda insane and half-cocked
e
Yeah, I think the two options are continuing down the Rube Goldberg path, but that requires Pants mods to support; so that's a further sign, or working out 1st class support for this sort of scenario.
f
I mean, the "eventual" fix would be first class support of execution of stages in containers and 
rpm_python_*
targets that could be contributed back as a backend
I was looking for something hackier to do a proof of concept in the short-term
e
Yeah, your hacks would need to expand into Pants mods. Pants currently only supports splitting PEXes when running 
./pants package
.
So your hack probably needs to involve a Pants branch and using 
pants_from_sources
to demo in the short term.
5 Views
Open in Slack
PreviousNext
Powered by