Running version Pants version

2.21.0

with interpreter constraints set to

==3.12.3

on MacOS sequioa 15.0.1. One of our developers is trying to build a Dockerfile which uses

cryptography==43.0.1

. He is getting the following error message:

> [deps 3/3] RUN PEX_TOOLS=1 python /app/api.deps.pex venv --scope=deps --compile /bin/app:

1.383 1.) /usr/local/bin/python3.12 CPython==3.12.3
1.383 2.)       /usr/bin/python3.11 CPython==3.11.2
1.383 
1.383 No interpreter compatible with the requested constraints was found:
1.383 
1.383   A distribution for cryptography could not be resolved for /usr/local/bin/python3.12.
1.383   Found 1 distribution for cryptography that do not apply:
1.383   1.) The wheel tags for cryptography 43.0.1 are cp39-abi3-macosx_10_9_universal2 which do not match the supported tags of /usr/local/bin/python3.12:
1.383   cp312-cp312-manylinux_2_36_aarch64
1.383   ... 608 more ...
------

Installing the package in a virtual environment without Pants and Pex, with a plain

pip3 install cryptography==43.0.1

seems to work just fine and outputs:

Collection cryptography==43.0.1
  Downloading cryptography-43.0.1-cp39-abi3-macosx_10_9_universal2.whl.metadata (5.4 kB)

As part of the download process. Why does this work, and is it possible to force pants to use this wheel even if the tags seemingly don't match, or is there an alternative solution that is better? Maybe I have to build the wheels myself and upload them to a registry? Looking at https://pypi.org/project/cryptography/43.0.1/ it doesn't seem like there are any python3.12 specific wheels being built at all.

Based on the Dockerfile snippet it looks like you’re building

pex_binary

targets before running in the Dockerfile; one thing that might help is specifying the

complete_platforms

for your PEX binary in addition to the interpreter constraints: https://github.com/pantsbuild/pants/blob/81d6e43b3b6618c97908e84afec097e15f003fb2/docs/docs/python/overview/pex.mdx#generating-the[…]_platforms-file

all the platform-specific third-party packages that your PEX transitively depends on must be available as prebuilt wheels for each platform you care about. If those wheels aren't available on PyPI you can always build them manually once and host them on a private package repository

So most likely the pip install is a bit misleading, and it's actually compiling from source at install-time? So I'd have to build the wheel myself and host it in a Python repository if I'm reading the gist correctly.

That piece of the docs only applies if you’re building for a different target platform than the one you’re running Pants on, ex: you’re building a PEX binary for Linux, on a Mac machine. Is that the case for you?

I ... think so? We're building the PEX that will be ran in an image based on Python3.12 from Dockerhub inside a local kind-cluster.

In that case, I’d strongly suggest setting your

complete_platforms

when building the PEX - you can generate the complete_platforms JSON file inside your Docker image using the instructions I linked above. When you installed the package using

pip

, notice that the wheel being pulled is a MacOS wheel (corresponding to your local dev environment).

Collection cryptography==43.0.1
  Downloading cryptography-43.0.1-cp39-abi3-macosx_10_9_universal2.whl.metadata

You’ll want to make sure that you build the PEX with platforms that match your target runtime (Linux) rather than Mac. So I’m guessing that is at least part of the problem.