When a 32-bit x86 system is run under emulation on a 64-bit CPU, `platform_machine` may still evaluate to `x86_64`. This makes it difficult to accurately distinguish 32-bit runtime environments using the existing PEP 508 environment markers.
To address this, I believe it would be useful to add a new PEP 508 environment marker based on `platform.architecture()`.
This may be a Docker bug. However, I believe `platform_architecture` would identify the system bitness more accurately than `platform_machine`, which relies on information obtained via `uname`.
If you are referring to the platform.architecturefunction, even that is not always reliable: note the note about multi-architecture binary files, like macOS universal (fat) files.
Would it make sense to add `sys.maxsize` as a PEP 508 environment marker?
Using sys.maxsizehas always been a bit of a kludge, IMHO. I think it would be better to try to improve detection within the platform module and also see if there are other, newer architecture attributes that are of importance. Probably worthy of writing a PEP for someone who is interested in pursuing it.
There was a stalled effort to standardize environment markers for ABI details:
Unfortunately I don’t think Klaus can continue that but IMO something standardizing ABI details like bitwidth and free-threaded/GIL-enabled is sorely needed.
As Nathan mentioned, PEP 780: ABI features as environment markers seems to cover exactly what I need, so we can keep an eye on how it evolves.
I wasn’t aware Docker did anything special at all to hide or emulate CPUs.
Even if the bug occurs in QEMU and the information is available, is this use case applicable to enough users, to warrant starting an arms race to circumvent emulation?
You’re supposed to distinguish the runtime environment through the platform tag, not through environment markers.
The platform_ in platform_machine is hinting at the platform module, which intentionally bypasses the runtime environment and asks the OS. I don’t know what the right answer for your particular case is, but on Windows (which supports transparent 32-bit and 64-bit emulation, but not cross-loading) you need to match the platform tag to get the properly compiled module.
You’d only use platform_machine for a pure-Python package that has architecture-specific code in it that doesn’t run as part of Python. It’s a very narrow case, but I can’t actually think of another case where it would be right to install the package for the machine rather than the runtime environment.
Unfortunately I don’t think anyone is actively working on it right now.
I moved this to Packaging as it seemed a better fit.