[BUG] Incompatible bdist_wheel.universal and requires-python behaviors build misleading "py2" package

[dbarnett]

setuptools version

setuptools==68.1.2

Python version

Python 3.12.3

OS

Ubuntu Linux 24.04

Additional environment information

No response

Description

Packages built with bdist_wheel.universal seem to promote py2 usage even when combined with project.requires-python = ">= 3". Could that be changed to stop implying py2 compatibility and/or have better docs & messaging to clarify how it works?

The option name bdist_wheel.universal sounds pretty generic for something that triggers such arcane behavior, and it's not super clear from docs whether universal is supposed to have any meaning anymore after py2 EOL.

Note: Originally reported at pypa/build#806, was told to report here instead.

Expected behavior

When I build packages that explicitly don't support python 2, I'd like to avoid PyPI saying simultaneously that it's a "Python 2" distribution and that it requires Python 3:

I think that entails removing the "py2" from the wheel filename.

How to Reproduce

1. Clone https://github.com/insanum/gcalcli/tree/4dabc51664aad65db282668769e85db83a057bb5
2. Run python -m build
3. Look at the output filenames and/or a preview of the published project on TestPyPI

Output

From python -m build:

Successfully built gcalcli-4.4.0.tar.gz and gcalcli-4.4.0-py2.py3-none-any.whl

From published https://pypi.org/project/gcalcli/4.4.0/#files:

Built Distribution
gcalcli-4.4.0-py2.py3-none-any.whl (43.2 kB see hashes))
Uploaded about 8 hours ago (Python 2) (Python 3)

Requires: Python >=3.8

[dbarnett]

Related: #1633 for python_requires handling.

[henryiii]

Since setuptools doesn't support Python 3.7 and earlier, would it maybe make sense to deprecate this option and make it a no-op?

[dbarnett]

That would suit me fine. Possibly a no-op that spits out a warning suggesting to clean up the unused option?

I've removed it from my project configs already, but by now sunk quite some time into understanding what it does after inheriting an old config that still had it set.

[abravalheri]

@henryiii, I think that is the best thing to do.

In theory someone could try to use that option to package Python code that is compatible with old versions of Python to support old systems, but since Python 2.7 itself reached EoL, that does not make much sense to me.

We can also put a call to action in the warning to contact us if the user needs this option.

[jaraco]

Since setuptools doesn't support Python 3.7 and earlier, would it maybe make sense to deprecate this option and make it a no-op?

I should say that when Setuptools dropped support for Python 2, it was dropping support for running under Python 2 but not necessarily dropping support for targeting Python 2. That is, one might build a wheel on Python 3.13 that targets Python 2.7. I note also that Python 2.7 is still supported by PyPy and Jython and IronPython (to the extent that those implementations are supported).

I personally don't have any projects targeting Python 2, although I do still use projects that rely on it (Moneydance uses Jython). I do also have backports that if they ever needed a security fix might need to target Python 2 (seems unlikely at this stage). I would not be surprised if there were other environments out there that still target it.

I think the OP's issue is a case of the user holding it wrong. "universal" means "build me something that works on Python 2 and Python 3". If the user is indicating universal, it should indicate Python 2. I learned this early on when I first released my packages for Python 3 only, but they still had the .py2 designation. At first I was dismayed, but then I realized all I needed to do was remove the universal config from my projects and everything was fine.

By deprecating universal, we're deprecating targeting Python 2, and that seems fine. Users can pull an older setuptools if needed to target Python 2.

[dbarnett]

I think the OP's issue is a case of the user holding it wrong. "universal" means "build me something that works on Python 2 and Python 3".
…
At first I was dismayed, but then I realized all I needed to do was remove the universal config from my projects and everything was fine.

Yup, I mostly agree with that, just with the misfeature that nothing told me I was doing it wrong or how to do it right. So to close this out, could someone just toss a warning into the build somewhere saying "consider removing universal, conflicts with requires-python"?