pip install failed on MacOS Big Sur because build wheel with unsupported tag

[jcwchen]

Hi,
Currently our Python package (ONNX) encounters a build error while pip install it on the latest MacOS version (Big Sur).
The script we used:

#!/bin/bash
git clone --recursive https://github.com/onnx/onnx.git
python -m venv env
source ./venv/source/activate
export ONNX_ML=1
export ONNX_NAMESPACE=onnx
python -m pip install --upgrade pip
python -m pip install --use-feature=2020-resolver --upgrade protobuf
python -m pip install ./onnx

The error is as follows:

  Copying onnx.egg-info to build/bdist.macosx-10.15-x86_64/wheel/onnx-1.8.0-py3.8.egg-info
  running install_scripts
  [WARNING] This wheel needs a higher macOS version than the version your Python interpreter is compiled against.  To silence this warning, set MACOSX_DEPLOYMENT_TARGET to at least 11_0 or recreate these files with lower MACOSX_DEPLOYMENT_TARGET:
  build/bdist.macosx-10.15-x86_64/wheel/onnx/onnx_cpp2py_export.cpython-38-darwin.soTraceback (most recent call last):
    File "/Users/xxxxxxxxxx/env/onnx/lib/python3.8/site-packages/pip/_vendor/pep517/_in_process.py", line 280, in <module>
  AssertionError: would build wheel with unsupported tag ('cp38', 'cp38', 'macosx_11_0_x86_64')

I suspect it might be a pip issue instead of the Python library (ONNX) issue. Has wheel packaging supported the latest macOS (11.0) yet? At least I don't see such tag (cp-38-cp38-macosx_11_0_x86_64) in my local packaging.list(tags.sys_tags().
Could anyone help me to take a look at this issue? Thank you!

Reference: onnx/onnx#3114

[agronholm]

That error is something that wheel would produce. Can you paste the list of supported tags on your system?

[jcwchen]

Here is the file. Thank you.
sys_tags.txt

[agronholm]

I don't have the expertise to debug this, so I'm calling out for those with macOS platform expertise to help.

[agronholm]

This is the likely cause: pypa/packaging#318

[jcwchen]

I believe this is the reason. Thank you @agronholm for the investigation!

[agronholm]

Why did you close the issue? It's still a problem with wheel, and I need to vendor the updated packaging library once they've fixed the problem upstream.

[jcwchen]

Oh sorry I thought this issue is only related to their side and don't want to bother here. Tracking the issue here is also good. Thank you.

[jcwchen]

I believe the latest version of packaging (20.5) should solve this issue.

[matt-dalton]

Thanks for the pointer @jcwchen ...although doesn't seem to be working for me. I'm getting this issue with multiple packages (lazy-object-proxy, pyyaml, tornado, simplejson, psycopg2).

Is there anything else I need to do other than pip3 install packaging==20.5?

Current versions are:
wheel 0.35.1
pip 20.2.4
packaging 20.5
Python 3.8.2

[jcwchen]

Your version setting looks good to me and only updating packaging==20.5 works for ONNX...

[agronholm]

Wheel has packaging vendored so updating packaging via pip will not fix the problem. I need to update the vendored packaging in wheel and make a new release.

[agronholm]

I've updated the vendored packaging now. Let me know if the problem persists.

[agronholm]

Once this has been tested to work, I will make a new release.

[agronholm]

If a mac user with Big Sur could test the latest master and confirm that it works, I could go ahead and make a release.

[matt-dalton]

I can test, but struggling to work out how to fix my wheel version to master. Would you be able to give me some pointers?

[agronholm]

I was able to add Big Sur to the Github Actions test matrix and the tests passed, so this is not strictly necessary. But for reference, doing pip install wheel@git+http://github.com/pypa/wheel will install the master version.

[matt-dalton]

Amazing thanks. Weirdly 4/5 libraries now seem to install fine, but I still get the same error with lazy-object-proxy.

[agronholm]

What makes lazy-object-proxy different? Can somebody else verify that this particular package still has problems?

[dreness]

Greetings; I think I'm also afflicted by this problem, or something similar. I encountered this while building out a fresh python3.9 venv and then installing various packages into it. python3.9 is provided by brew, but all package management happens with pip inside a virtualenv (via virtualenvwrapper). pip install scikit-learn reliably fails with:

      assert tag in supported_tags, "would build wheel with unsupported tag {}".format(tag)
  AssertionError: would build wheel with unsupported tag ('cp39', 'cp39', 'macosx_11_0_x86_64')

complete output: pip-install-scikit-learn.txt

Checking my supported tags, it does seem as though "macosx_11_0_x86_64" is not represented. I also tried updating wheel with pip install wheel@git+http://github.com/pypa/wheel but that didn't seem to help.

Also (not sure if this is strictly related to this issue's problem): I noticed that the scikit-learn build (and maybe others?) are not building with the expected toolchain; below we see that the default toolchain isn't the one being invoked.

❯ xcode-select -p
/Applications/Xcode-GM.app/Contents/Developer

(excerpt from pip-install-scikit-learn.txt)

  C compiler: clang -Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/Tk.framework/Versions/8.5/Headers

In this case, Xcode.app should generally be valid, but is a slightly older version than Xcode-GM.app and only has a macOS SDK - not the iOS family of SDKs (there's a reason ;).

[agronholm]

If those packages aren't using the installed wheel version to build, there's nothing I can do about it. Could you investigate a little bit?

[matt-dalton]

I'll also raise an issue with lazy-object-proxy to see if there's any weirdness with how they're using wheel - I really don't know enough about how it works to dig much deeper.

Is this preventing a release with this fix going out? It did seem to at least fix some libraries for me, so wondering if an official release would solve some problems.

[agronholm]

That is my thinking as well. I'll make a release ASAP.

[agronholm]

Can you test again now that v0.36.0 is out?

[matt-dalton]

Forgot to say actually - lazy-object-proxy was overriding my local version of wheel. When I forked the library and removed the relevant config file it worked. So I'm fairly sure your fix is sound.

I'll try again later with the new release to see if this fixes the issue more broadly 👍

[agronholm]

How was it overriding the wheel version?

[matt-dalton]

Maybe I'm not explaining correctly, but this file meant that it didn't seem to use the master version of wheel I was using: https://github.com/ionelmc/python-lazy-object-proxy/blob/master/pyproject.toml

[navin-680]

assert tag in supported_tags, "would build wheel with unsupported tag {}".format(tag)
AssertionError: would build wheel with unsupported tag ('cp39', 'cp39', 'macosx_11_0_universal2')

not able to run command pip install flirimageextractor

ERROR: Could not build wheels for numpy, which is required to install pyproject.toml-based projects

[henryiii]

All of "flirimageextractor"'s dependencies are exactly pinned down to the patch release - see https://github.com/nationaldronesau/FlirImageExtractor/blob/master/pyproject.toml. It's very likely there are old, buggy versions of things that have this old bug. If you don't pin numpy like that, you should get a wheel that works on ARM, for example, rather than trying to build an (unsupported) version. You should open an issue here: https://github.com/nationaldronesau/FlirImageExtractor/issues, I think.