You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently tools subcommands like PEX_TOOLS=1 ./some.pex venv ... work with the current OS/python interpreter as the target of interest, and give information/exports based on how the PEX file would run in this environment (potentially an error). https://gist.github.com/huonw/adbd1d685f595d10780e5f878a5245cd
It would be convenient if it was possible for a venv or flat layout (#2110) to be exported for other targets, as this would make it easier to, for instance, construct simple artefacts for running in FaaS platforms like AWS Lambda:
construct a PEX using a complete platforms JSON for the Lambda environment
export the PEX's first and third party code using the same complete platforms JSON for the Lambda environment
Currently, step 2 needs to be run in a docker container with compatible tags, and this can be awkward (e.g. pants only recently got (experimental) support for docker environments) and slow (e.g. it may even require CPU emulation, like building an x86-64 lambda on arm64 macOS, or an arm64 lambda on x86-64 linux, or whatever other combination).
(NB. even with this feature, step 1 may need to be run in a docker container, if there's any platform-specific sdists to build. This feature request is just about step 2, not changing step 1. IME, we can get a long long way without this: we deploy many lambdas using only bdists and platform-independent sdists.)
@huonw this is pretty broad and completion would entail porting every pex-tool to a pex3 command. #2140 does this for venv creation which seems like an important one.
In particular, what is the use case for repository info for a foreign platform exactly?
More broadly, is their a priority ordered list you could provide of the other pex-tools sub-commands that you need? Either this issue will need some tighter scope to get closed in the next year or else it will just be a very long term umbrella issue that needs to grow a checklist.
For my use case (laying out static AWS Lambdas artefacts), #2140 is indeed the only important one. I'll reframe to just be that one, so that this can be closed off, and if someone has a use case for something else, they can push for it.
huonw
changed the title
Allow pex tools to query/export for platforms other than the current one
Allow pex venv to export dependencies/first-party code for platforms other than the current one
May 1, 2023
Currently tools subcommands like
PEX_TOOLS=1 ./some.pex venv ...
work with the current OS/python interpreter as the target of interest, and give information/exports based on how the PEX file would run in this environment (potentially an error). https://gist.github.com/huonw/adbd1d685f595d10780e5f878a5245cdIt would be convenient if it was possible for a venv or flat layout (#2110) to be exported for other targets, as this would make it easier to, for instance, construct simple artefacts for running in FaaS platforms like AWS Lambda:
(https://docs.aws.amazon.com/lambda/latest/dg/python-package.html#python-package-create-package-with-dependency steps 4-6)
Currently, step 2 needs to be run in a docker container with compatible tags, and this can be awkward (e.g. pants only recently got (experimental) support for docker environments) and slow (e.g. it may even require CPU emulation, like building an x86-64 lambda on arm64 macOS, or an arm64 lambda on x86-64 linux, or whatever other combination).
(NB. even with this feature, step 1 may need to be run in a docker container, if there's any platform-specific sdists to build. This feature request is just about step 2, not changing step 1. IME, we can get a long long way without this: we deploy many lambdas using only bdists and platform-independent sdists.)
More discussion: https://pantsbuild.slack.com/archives/C046T6T9U/p1680247328906249
The text was updated successfully, but these errors were encountered: