Is there a way to take a pex_binary target and create a requirements.txt file from it? It's a follow up from a previous question - but I'm trying to cross-platform build docker images and it is really really slow. Like 100x+ slower when building arm from x86. I'm wondering if it would be easier to download all packages at runtime instead. I want the packages from a pex compile to do that though. Will take any advice.

To literally generate a requirements.txt you could -- among various PEX_TOOLS tricks -- run

pip freeze

https://github.com/pantsbuild/pants/discussions/20368 For what you are trying to do though, there are several variant of using

complete_platform

to assemble an x86_64 pex on arm64, or vise versa. You could then, for example, use copy the right wheels around. (The details are obviously specific to what you are trying to do, but in general if one is trying to deploy on arch X, it would be advisable to also test/build on arch X too.)

complete_platform gets me the whls, but running pex compile in a

docker_image

rule for a cross platform build is obnoxiously slow. Usually we're running on x86, but we also need to support arm builds soon. I rebuilt all our deps for arm on an arm machine and even made an arm deployment work, but most people are working on x86 machines and need the ability to test runs on x86 or arm.

https://www.pantsbuild.org/blog/2022/08/02/optimizing-python-docker-deploys-using-pants but build your deps and publish, then the second layer always pull the deps layer and stack local code on top.

We already do all of that 🙂 Took about 1.5 hours to build the largest intermediate image. Trying to figure it out if that's okay for us.

To answer the OP directly - lots of ways:

# Using external pex-tools:
:; pex requests -o requests.pex

:; pex-tools requests.pex repository info -v | jq -r '.project_name + "==" + .version'
requests==2.32.5
charset-normalizer==3.4.4
idna==3.11
urllib3==2.5.0
certifi==2025.10.5

# Using embedded pex tools (comes along with --venv PEXes for free as well)
:; pex requests -o requests.pex --include-tools

:; PEX_TOOLS=1 ./requests.pex repository info -v | jq -r '.project_name + "==" + .version'
requests==2.32.5
charset-normalizer==3.4.4
idna==3.11
urllib3==2.5.0
certifi==2025.10.5

# No pex tools at all
:; unzip -qc requests.pex PEX-INFO | jq -r '.distributions | keys[]' | cut -d- -f1-2 | sed -e 's|-|==|'
certifi==2025.10.5
charset_normalizer==3.4.4
idna==3.11
requests==2.32.5
urllib3==2.5.0

Per the blog above, we're still running pex compile in the container build steps. I think that's causing some of the slowness I'm seeing

For example, see here: https://github.com/pex-tool/pex/issues/2949#issuecomment-3408725425 Build an aarch64 Linux PEX on x86_64 Linux.

This is for a comically large image

I saw that, but if your image is running under emulation, that alone explains slowness of running anything at all.

I know. Was asking here hoping for a better solution 😞

I am giving that! Do not use a container

So we can build the pex env, but we need the container for orchestration purposes. We can't do anything like stage the pex and then pull it in during startup time for a silly reason I can't get into.

Alrighty then. Well you will have no solutions if you're forced to build the PEX in the container.