Unexpected dependency resolving with `platform_machine` and `--python-platform`

[schlamar]

Summary

Passing --python 3.9 --python-platform i686-pc-windows-msvc to uv results in different dependency resolving than using --python cpython-3.9-windows-x86-none.

Minimal example pyproject.toml

[project]
name = "test"
version = "0.1"
dependencies = [
    "greenlet >= 1;(platform_machine=='aarch64' or (platform_machine=='ppc64le' or (platform_machine=='x86_64' or (platform_machine=='amd64' or (platform_machine=='AMD64' or (platform_machine=='win32' or platform_machine=='WIN32'))))))",
]

Note: this is a real world example extracted from SQLAlchemy: https://github.com/sqlalchemy/sqlalchemy/blob/rel_2_0/setup.cfg#L41

Running uv sync --python cpython-3.9-windows-x86-none results in greenlet getting installed. Running uv sync --python 3.9 --python-platform i686-pc-windows-msvc greenlet is missing.

I would have expected that both commands would behave exactly the same and greenlet is getting installed in both cases.

Platform

Windows 11 x86_64

Version

uv 0.9.7 (0adb444 2025-10-30)

Python version

Python 3.9.13

[charliermarsh]

Can you tell me what platform_machine value the cpython-3.9-windows-x86-none Python returns? I don't have my Windows machine on me. (It's import platform; platform.machine().)

[schlamar]

This returns the architecture of the machine / processor and not the architecture of the running Python interpreter:

> py -3.9-32 -c "import platform; print(platform.machine())"
AMD64
> py -3.10-64 -c "import platform; print(platform.machine())"
AMD64

[charliermarsh]

I think Self::I686PcWindowsMsvc => "x86" is probably wrong. We shouldn't be returning x86 there.

[charliermarsh]

Wait sorry, I think that's correct. Can you explain why you would expect Greenlet to be installed in both cases? Are you intending to use x86_64? x86 on its own is quite rare now.

[schlamar]

uv sync --python cpython-3.9-windows-x86-none does install greenlet x86 wheel.

uv sync --python 3.9 --python-platform i686-pc-windows-msvc does not install x86 greenlet wheel.

Both commands install x86 wheels (for example SQLAlchemy) if there is no platform_machine marker.

So my guess is that uv is misbehaving in combination with the platform_machine marker.

[charliermarsh]

But, to clarify, why would --python-platform i686-pc-windows-msvc install the x86 greenlet wheel? x86 is not listed in the marker set:

(platform_machine=='aarch64' or (platform_machine=='ppc64le' or (platform_machine=='x86_64' or (platform_machine=='amd64' or (platform_machine=='AMD64' or (platform_machine=='win32' or platform_machine=='WIN32'))))))

[charliermarsh]

(#15060 might be relevant? The fact that --python cpython-3.9-windows-x86-none installs the greenlet wheel seems wrong but also hard to avoid because platform_machine returns the host architecture, not the Python architecture.)

[schlamar]

Ah I see. I guess you are misinterpreting how the platform_machine marker is designed to work. I totally understand though as this is pretty weird - especially on Windows.

The essential part: The platform_machine marker does not correspond to the platform part of the Python target triple.

A `platform_machine=='AMD64' marker basically says I need this dependency on a Windows 64bit host. It does not say I need a wheel for a 64bit Python interpreter.

If you run a 32bit interpreter on a 64bit Windows, greenlet has to be installed if the following is configured

"greenlet;platform_machine=='AMD64'"

#15060 is definitely related - I assume this has the same root cause.

[charliermarsh]

I think I have a good understanding of the problem, I'm just not sure that anything should actually be changed here.

If you pass --python-platform i686-pc-windows-msvc, we have to choose some value for platform_machine, and it seems more incorrect to choose AMD64 instead of x86. Like, if you say you're installing for a 32-bit architecture, why would we assume it's a 64-bit machine?

Similarly, is it even intentional (from SQLAlchemy's perspective) that greenlet is installed on an i686 Python? They don't even ship wheels for that architecture beyond Python 3.9. My guess is they're using it the way that most people assume it is meant to be interpreted (i.e., that you're on a Python that can run AMD64 wheels)?

Regardless, I am not really convinced that anything should change here given the limitations in the marker design. What would you expect to change?

[schlamar]

Looking at the values from sqlalchemy above I assume the value for platform_machine on a 32bit Windows should be `WIN32` and not `x86`. However, I would expect if you run uv on a Windows host it reads the platform_machine from the host and not from the value passed to python-platform. This leaves only the ambiguous case where you "cross" target from non Windows host to a Windows host. I think AMD64 might be the better default for this case. There is no Windows 11 32bit, so a 32bit Windows host is quite rare these days. Running a 32bit interpreter on a 64bit Windows host is much more common. 05.11.2025 14:58:17 Charlie Marsh ***@***.***>:

…

[Bild]*charliermarsh* left a comment (astral-sh/uv#16576)[#16576 (comment)] I think I have a good understanding of the problem, I'm just not sure that anything should actually be changed here. If you pass *--python-platform i686-pc-windows-msvc*, we have to choose some value for *platform_machine*, and it seems more incorrect to choose *AMD64* instead of *x86*. Like, if you say you're installing for a 32-bit architecture, why would we /assume/ it's a 64-bit machine? Similarly, is it even intentional (from SQLAlchemy's perspective) that greenlet is installed on an i686 Python? They don't even ship wheels for that architecture beyond Python 3.9. My guess is they're using it the way that most people assume it is meant to be interpreted (i.e., that you're on a Python that can run AMD64 wheels)? Regardless, I am not really convinced that anything should change here given the limitations in the marker design. What would you expect to change? — Reply to this email directly, view it on GitHub[#16576 (comment)], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AAB2IPG26UKKITBUKEXMCKD33H66RAVCNFSM6AAAAACK7AEEOGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTIOJRGM2TONZUGQ]. You are receiving this because you authored the thread. [Verfolgungsbild][https://github.com/notifications/beacon/AAB2IPHKLZEAQXB6EMAQLBD33H66RA5CNFSM6AAAAACK7AEEOGWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTWQDHSDA.gif]

[charliermarsh]

Looking at the values from sqlalchemy above I assume the value for platform_machine on a 32bit Windows should be WIN32 and not x86.

From my research, I don't think this is true (though I don't have a machine handy to test it on), it seems that it returns PROCESSOR_ARCHITECTURE which is x86 on 32-bit Windows. win32 is commonly the sys.platform value, but AFAICT platform.machine is x86.

[charliermarsh]

We could consider changing the platform_machine value to AMD64 but it shouldn't be dependent on the host machine. It's very important that those values are totally independent of the host.