Fails to build wheel for Python 3.10

[uranusjr]

Encountered while looking into pypa/pip#8312.

$ python --version  # Built from master.
Python 3.10.0a0
$ python -c 'import setuptools; print(setuptools.__version__)'
46.0.0
$ python -m pip install --no-build-isolation -U "wheel @ git+https://github.com/pypa/wheel.git"
...
Successfully installed wheel-0.34.2
$ git clone https://github.com/cython/cython.git
$ cd cython
$ python setup.py bdist_wheel
...
running install_scripts
Traceback (most recent call last):
  File "cython/setup.py", line 291, in <module>
    run_build()
  File "cython/setup.py", line 228, in run_build
    setup(
  File "pip-8312/lib/python3.10/site-packages/setuptools/__init__.py", line 144, in setup
    return distutils.core.setup(**attrs)
  File "python3.10/lib/python3.10/distutils/core.py", line 148, in setup
    dist.run_commands()
  File "python3.10/lib/python3.10/distutils/dist.py", line 966, in run_commands
    self.run_command(cmd)
  File "python3.10/lib/python3.10/distutils/dist.py", line 985, in run_command
    cmd_obj.run()
  File "pip-8312/lib/python3.10/site-packages/wheel/bdist_wheel.py", line 328, in run
    impl_tag, abi_tag, plat_tag = self.get_tag()
  File "/lib/python3.10/site-packages/wheel/bdist_wheel.py", line 278, in get_tag
    assert tag in supported_tags, "would build wheel with unsupported tag {}".format(tag)
AssertionError: would build wheel with unsupported tag ('cp310', 'cp310', 'linux_x86_64')

It seems like bdist_wheel is using different tag schemes to build and check the tags. The assertion uses packaging.tags, which correctly tag Python 3.10 as cp3_10 (see pypa/packaging#240), but the build part incorrectly tries to use cp310, causing the assertion error.

---

Side note: The sdist has a packaging issue. --no-build-isolation is needed since otherwise the build fails with ModuleNotFoundError: No module named 'packaging'.

[mattip]

I think this should be fixed by gh-346 which changes wheel to use packaging underneath. Could you check what happens if you `python -m pip install git+https://github.com/pypa/wheel@master which should install a newer wheel then try to build your package's wheel?

[uranusjr]

The assertion error is introduced by #346. Prior to the patch, bdist_wheel would “successfully” produce a wheel with an invalid tag Cython-3.0a5-cp310-cp310-linux_x86_64.whl. After the patch, wheel uses the same logic as before to generate the wheel tags, but the assertion prevents the actual wheel generation because it correctly identifies that the wheel tags would be invalid.

[mattip]

Thanks for the clarification. I think this is coming from sysconfig.get_config_var('py_version_nodot') which is called by tags.interpreter_version() which is called by bdist_wheel. Could you check whether sysconfig.get_config_var('py_version_nodot') is 310 or 3_10 ?

[uranusjr]

sysconfig.get_config_var('py_version_nodot') returns 310.

[mattip]

:(. I opened the linked issue in packaging, since it is a CPython problem it will be tricky to fix.

[dimaqq]

Kind ping, since Python-3.10.0a1 is out, and it would be awesome to test our code and oss libraries, but a few can't be built😭

[pquentin]

@dimaqq I think python/cpython#20333 needs to be merged first

[agronholm]

Yeah, doesn't seem worthwhile to fix this from the wheel side.

[markshannon]

Why does pip use a text decimal version, rather the tuple of numbers from sys.version_info?
It does seem rather fragile?

wheel/src/wheel/vendored/packaging/tags.py

Line 815 in 64550e1

# type: (bool) -> str

[mattip]

So avoid the 310 vs 3_10 problem altogether by always using (3, 10) instead? Interesting. I wish I would have thought of that 6 months ago. :)

[mattip]

Since both pip and wheel vendor in versions of packaging, they might be able to deal with an ABI-breaking change.

[domdfcoding]

pypa/packaging#355 has now been merged, and is included in included in the 20.8 release. I think that should fix this issue. It will just need a new version of wheel with the latest packaging vendored.

[RhinosF1]

a new version of wheel

Do we know when this is due out?

[mattip]

Probably in a day or two, judging by this comment. But these things take time, there are usually last-minute snags.

[agronholm]

I've released v0.36.2 now.

[RhinosF1]

I've released v0.36.2 now.

Working for me now with 3.10 alpha 3

Yey!

[frenzymadness]

Hello, I might find a regression in the latest releases. Is that a problem in the wheel or somewhere else or is it just me doing something wrong?

# pip list 
Package    Version
---------- -------
pip        21.0.1
setuptools 53.0.0
wheel      0.36.2

# python -V
Python 3.10.0a5

# pip install numpy
Collecting numpy
  Using cached numpy-1.20.1.zip (7.8 MB)
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
    Preparing wheel metadata ... done
Building wheels for collected packages: numpy
  Building wheel for numpy (PEP 517) ... error
… very long output …
AssertionError: would build wheel with unsupported tag ('cp310', 'cp310', 'linux_x86_64')
…
ERROR: Could not build wheels for numpy which use PEP 517 and cannot be installed directly

[uranusjr]

Can you post the “very long output” part?

[fochoao]

This works for Windows 10, prebuilt binaries, wheel totally working on alpha 5. https://github.com/fochoao/cpython

[agronholm]

The scientific Python stack is notorious for their home grown packaging tools, so this might be a problem with an outdated, vendored wheel.

[agronholm]

I was right: https://github.com/numpy/numpy/blob/master/pyproject.toml#L5

[uranusjr]

Seems like they’re choosing the upper version cap to make sure the build environment is predictable. I think they’d be very willing to update the declaration if you raise the issue to them.

[frenzymadness]

Thank you all, I'm gonna propose a fix there!

[fochoao]

Check out my cpython build, I got wheel fully running in https://github.com/fochoao/cpython however all is compiled mostly for Windows 10. CPython 3.10.0 alpha 7.

[The-Compiler]

@fochoao Let me note that (at least for x86 and x86_64), official release binaries are available. This has nothing to do with building wheels of Python packages (which this issue is about), however.

[fochoao]

@fochoao Let me note that (at least for x86 and x86_64), official release binaries are available. This has nothing to do with building wheels of Python packages (which this issue is about), however.

Try https://github.com/python/cpython/ for the real deal. Hope that helps.