uv export creating constraint files that use python_full_version where they could be using just python_version

[gibsondan]

Summary

Running 'uv export --no-hashes' on this pyproject.toml file:

[project]
name = "jaffle_platform"
requires-python = ">=3.9,<3.13"
version = "0.1.0"
dependencies = [
    "pytest",
]

Outputs this:

# This file was autogenerated via `uv export`.
colorama==0.4.6 ; sys_platform == 'win32'
exceptiongroup==1.2.2 ; python_full_version < '3.11'
iniconfig==2.0.0
packaging==24.2
pluggy==1.5.0
pytest==8.3.4
tomli==2.2.1 ; python_full_version < '3.11'

Note the line that says

python_full_version < '3.11'

Should this instead ve

python_version < '3.11'

?

python_full_version is not available in all build environments, notably PEX when using the --platform argument: https://pex.readthedocs.io/en/v2.1.66/buildingpex.html#platform

So this issue makes it impossible to run uv export and pass the result into PEX to build a PEX file from a uv project.

Platform

Darwin 23.6.0 arm64

Version

uv 0.4.8 (956cadd 2024-09-09)

Python version

Python 3.11.9

[zanieb]

Hm. We always normalize these to the full version for consistency, as it avoids subtle bugs #6126

We could simplify them back to python_version in output when feasible, but I'm not sure it's worth it.

Why can't you use Pex's --complete-platform option? per

Constraints: when --platform is used the environment marker python_full_version is not available, because its value cannot be determined from a platform where only a two-digit string representing the python version can be specified (e.g., 38), while python_full_version is meant to have 3 digits (e.g., 3.8.10). If python_full_version is found an UndefinedEnvironmentName exception will be raised. To remedy this, use --complete-platform instead.

I'm not sure I entirely follow why they cannot support python_full_version there, but I'm not familiar with the workings of Pex.

[zanieb]

cc @jsirois I'd appreciate any context you could provide.

[gibsondan]

We’re looking into using —complete-platform - that might work to unblock us here.

[jsirois]

@gibsondan definitely use --complete-platform. That said, if you know the full version you're targeting, read the last paragraph of the --platform docs: https://docs.pex-tool.org/buildingpex.html#platform

@zanieb Pex historically (since maybe 2011) has supported cross-resolving with a --platform argument that looks like so: linux_x86_64-cp-36-cp36m. This argument is akin to the 4 Pip arguments: --platform, --python-version, --implementation, and --abi.

It's a bad idea, since the information supplied is not enough to use to impersonate an interpreter on the foreign platform with full fidelity for the purposes of evaluating environment markers and wheel tags.

That said, it works in many cases. I made the cases where it doesn't work strict. For --platform linux_x86_64-cp-36-cp36m and an environment marker python_full_version >= '3.6.2' I don't have enough information and fail fast. I don't even look at the marker condition, I just see python_full_version and die since that marker is intended to address X.Y.Z and python_version is generally used if the constraint is only sensitive to X.Y or just X.

It looks like uv often (always?) uses python_full_version even when the condition only needs python_version to evaluate correctly. This trips Pex up when evaluating a --platform resolve.

Hopefully that makes sense.

Clearly Pex could go the extra mile, parse the marker condition and rewrite as python_version when that's all that needed to allow the foreign --platform resolve to continue, but I've been actively discouraging --platform use for a while now; so I'm not inclined to go that extra mile.

[zanieb]

Thanks for taking the time to write that up!

It looks like uv often (always?) uses python_full_version even when the condition only needs python_version to evaluate correctly.

Yeah we always transform python_version to python_full_version so we don't need to worry about mixed representations when performing marker algebra (it's hard enough as is!).

[gibsondan]

--complete-platform is working great, so this is no longer blocking for us.

[zanieb]

I'll close this out for now — we can reconsider if there are more use-cases where the normalization is problematic.