Error when built wheel is for the wrong platform

[konstin]

Error when a built wheel is for the wrong platform. This can happen especially when using --python-platform or --python-version with uv pip install.

Fixes #16019

[konstin]

There are no changes in the ecosystem tests, so this is ready to be reviewed and merged.

[zanieb]

Is it possible that this can cause false positives or regressions?

What if we're just building the wheel for a resolve (i.e., uv pip compile) and don't care if it's not valid?

[konstin]

Is it possible that this can cause false positives or regressions?

What if we're just building the wheel for a resolve (i.e., uv pip compile) and don't care if it's not valid?

It's technically possible but for this too happen, we need to have a case where:

1. There is no static metadata
2. The build backend doesn't support prepare_metadata_for_build_wheel
3. The build backend always targets a specific platform
4. The user is running uv pip compile on a non-target platform. This excludes cases with uv pip compile -p pointing to a target Python that can be emulated on the host.

Of these, (3) is very unlikely, in my experience build backends only have limited cross-compiling support if any, and I've never seen one that defaults to a different platform than the current one. It would also be strange to me if a build backend wouldn't implement prepare_metadata_for_build_wheel, as the functionality is a subset of the build_wheel hook.

--python-platform is a bit fragile by design (PEP 517 has no concept of a target that can be given to build backends, you can only pass them a real Python interpreter as sys.executable), but I'm not aware of other cases where this would cause a regression.

[zanieb]

I'm wary because I think uv pip compile --python-platform is far more common than uv pip install --python-platform and I think this error can only cause regressions in the former / is only helpful for the latter.

What do you mean by (3)? Yes I would only expect most build backends to target the current platform and have no conception of cross-builds. Why would "always targets a specific platform" be needed for this to cause a regression?

[konstin]

That's a very good point, I added a test specifically for this. The good news is it's already passing as the metadata-only branch in DistributionDatabase doesn't pass around tags nor does it check them.

The stronger checks uncovered a bug in how we generate tags for Pyston: #16972. Merging this PR may uncover more such problems on non-PyPI platform that usually don't have built wheels.

[zanieb]

I'd probably consider this an "enhancement" rather than a "bug"

[mjamroz]

guys is there any way to ignore that error? With this upgrade we cannot install kinto-11.2.1-cp3-none-any.whl on alpine anymore

[konstin]

@mjamroz Can you please file a new issue with a reproduction? cp3-none-any is a very odd tag, should it by py3-none-any?

[mjamroz]

@konstin here you go #17061