Originally reported by: Marcus Smith (Bitbucket: qwcode, GitHub: qwcode)

bdist_wheel doesn't handle absolute paths in the "data_files" keyword like standard setuptools installs do, which honor it as absolute (which seems to match the examples in the distutils docs)

when using absolute paths, the data ends up in the packaged wheel at the top level, and get's installed relative to site-packages (along with the project packages)

so, bdist_wheel is re-interpreting distutil's "data_files" differently. maybe better for wheel to fail to build projects with absolute data_files, than to just reinterpret it.

• Bitbucket: https://bitbucket.org/pypa/wheel/issue/92

Fixes gh-345

First steps

• add packaging to setup and testing for CI
• make sure tests are run with a modern setuptools and pip
• concentrate all the uses of pep425tags in one place

Experiencing this error when pip install numpy and cryptography in Docker container on Raspberry. While images built in May and June of 2020 worked well. Tried and it didn't work:

• downgrading versions of wheel and packages,

• vice versa, upgrading pip, wheel and packages to the very latest versions

• pip install cryptography --no-binary cryptography

Maybe it is an arm64 issue. For instance, cryptography doesn't list this platform as supported https://cryptography.io/en/latest/installation/#build-on-linux

Workaround

pip install -e git+https://github.com/pyca/cryptography.git#egg=cryptography

Details

      File "/tmp/pip-build-env-n8ueeulb/overlay/lib/python3.8/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 ('cp38', 'cp38', 'linux_aarch64')
  ...
  ERROR: Could not build wheels for numpy which use PEP 517 and cannot be installed directly

OS : Raspbian GNU/Linux 10 (buster) Docker: 19.03.12 Base: python:3.8-buster

Specifically the build requirements state:

Project build requirements will define a directed graph of requirements (project A needs B to build, B needs C and D, etc.) This graph MUST NOT contain cycles. If (due to lack of co-ordination between projects, for example) a cycle is present, front ends MAY refuse to build the project.

However front ends MAY have modes where they do not consider wheels when locating build requirements, and so projects MUST NOT assume that publishing wheels is sufficient to break a requirement cycle.

This specific PEP517 Build requirements violation can be identified by the dependency cycle validator in build that I'm working on.

This flags the problem:

ERROR Failed to validate `build-system` in pyproject.toml, dependency cycle detected: `wheel` -> `setuptools.build_meta` -> `wheel`

We download wheel as a sdist and install it into a venv inside a docker container. As of 0.34, something changed so that we get a UnicodeDecodeError. Perhaps a unicode character slipped into a README or CHANGELOG? I'll try to get more details as I track it down further, but since wheel 0.34 was just released 4 hours ago, I wanted to get this report in as soon as I could.

954 pip install --ignore-installed --no-user --prefix /tmp/pip-build-env-6gct78aj/overlay --no-warn-script-location --no-binary :all: -i https://pypi.org/simple -- setuptools wheel
955        cwd: None
956   Complete output (27 lines):
957   Collecting setuptools
958     Downloading setuptools-45.1.0.zip (859 kB)
959   Collecting wheel
960     Downloading wheel-0.34.0.tar.gz (60 kB)
961   ERROR: Exception:
962   Traceback (most recent call last):
963     File ".tox/bundle/lib/python3.6/site-packages/pip/_internal/cli/base_command.py", line 186, in _main
964       status = self.run(options, args)
965     File ".tox/bundle/lib/python3.6/site-packages/pip/_internal/commands/install.py", line 331, in run
966       resolver.resolve(requirement_set)
967     File ".tox/bundle/lib/python3.6/site-packages/pip/_internal/legacy_resolve.py", line 177, in resolve
968       discovered_reqs.extend(self._resolve_one(requirement_set, req))
969     File ".tox/bundle/lib/python3.6/site-packages/pip/_internal/legacy_resolve.py", line 333, in _resolve_one
970       abstract_dist = self._get_abstract_dist_for(req_to_install)
971     File ".tox/bundle/lib/python3.6/site-packages/pip/_internal/legacy_resolve.py", line 282, in _get_abstract_dist_for
972       abstract_dist = self.preparer.prepare_linked_requirement(req)
973     File ".tox/bundle/lib/python3.6/site-packages/pip/_internal/operations/prepare.py", line 482, in prepare_linked_requirement
974       hashes=hashes,
975     File ".tox/bundle/lib/python3.6/site-packages/pip/_internal/operations/prepare.py", line 287, in unpack_url
976       hashes=hashes,
977     File ".tox/bundle/lib/python3.6/site-packages/pip/_internal/operations/prepare.py", line 164, in unpack_http_url
978       unpack_file(from_path, location, content_type)
979     File "].tox/bundle/lib/python3.6/site-packages/pip/_internal/utils/unpacking.py", line 261, in unpack_file
980       untar_file(filename, location)
981     File ".tox/bundle/lib/python3.6/site-packages/pip/_internal/utils/unpacking.py", line 222, in untar_file
982       with open(path, 'wb') as destfp:
983   UnicodeEncodeError: 'ascii' codec can't encode characters in position 72-74: ordinal not in range(128)

It looks like 0.33.2 change is incompatible with latest distlib package.

If I try to do distlib.wheel.install() it throws an error because folder ZipInfo object filename is not in the records: https://bitbucket.org/pypa/distlib/src/3b0fd333c8fb15bc04e570a23ee4836caefb7951/distlib/wheel.py#lines-521

I don't see any details about Folders in PEP (https://www.python.org/dev/peps/pep-0427/), so not clear if this is something that should be addressed by wheel or distlib package.

In this moment wheel package create python wheel with same platform tag like python was compiled. But wheel may contain libraries which needs higher macos version. In this patch I add code which scan all files added to wheel and if their suffix suggest that it is library (*.so or *.dynlib) and then try to determine macos version by scan Mach-O header. This code is pure python and do not depends on external files. The struct in comments are copied from Apple heade files.

To manually check library needs use otool on file. and look on LC_BUILD_VERSION or LC_VERSION_MIN_MACOSX section.

To set macosx minimum version set environment variable MACOSX_DEPLOYMENT_TARGET before compile. If compilation is launched with python setup.py ... then the version from variable need to be higher or equal than version returned by distutils.util.get_platform()

travis ci fail is connected with python 2.7.3 and occurs also in original data. It is not connected with my changes.

Originally reported by: pombredanne NA (Bitbucket: pombredanne, GitHub: pombredanne)

Using the latest setuptools, pip, virtualenv and wheel 0.24 on win7 74bits, Python 2.7.8 32bits.

When installed with pip install publicsuffix the publicsuffix.txt data files goes into site-packages side by side with the .py file

If I create a wheel from publicsuffix, and then install this wheel then the publicsuffix.txt data file gets installed in my current directory and not site-packages and the package becomes unusable

See https://pypi.python.org/pypi/publicsuffix/1.0.5 http://www.tablix.org/~avian/git/publicsuffix.git/ and a clone at: https://bitbucket.org/pombredanne/publicsuffix2/src?at=master

• Bitbucket: https://bitbucket.org/pypa/wheel/issue/120

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: https://github.com/onnx/onnx/issues/3114

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'.

When i build docker image I get an error below

Use:

• python:3.7.6-alpine3.10
• Docker version 19.03.5, build 633a0ea

      Collecting setuptools>=34.4
        Using cached https://files.pythonhosted.org/packages/42/3e/2464120172859e5d103e5500315fb5555b1e908c0dacc73d80d35a9480ca/setuptools-45.1.0.zip
      Collecting wheel
        Using cached https://files.pythonhosted.org/packages/15/39/728ccb81172c73f14084948b2d4561d5e51649dcf4b21d1f207b7363b1d7/wheel-0.34.0.tar.gz
      ERROR: Exception:
      Traceback (most recent call last):
        File "/usr/local/lib/python3.6/site-packages/pip/_internal/cli/base_command.py", line 188, in main
          status = self.run(options, args)
        File "/usr/local/lib/python3.6/site-packages/pip/_internal/commands/install.py", line 345, in run
          resolver.resolve(requirement_set)
        File "/usr/local/lib/python3.6/site-packages/pip/_internal/legacy_resolve.py", line 196, in resolve
          self._resolve_one(requirement_set, req)
        File "/usr/local/lib/python3.6/site-packages/pip/_internal/legacy_resolve.py", line 359, in _resolve_one
          abstract_dist = self._get_abstract_dist_for(req_to_install)
        File "/usr/local/lib/python3.6/site-packages/pip/_internal/legacy_resolve.py", line 307, in _get_abstract_dist_for
          self.require_hashes
        File "/usr/local/lib/python3.6/site-packages/pip/_internal/operations/prepare.py", line 213, in prepare_linked_requirement
          with self.req_tracker.track(req):
        File "/usr/local/lib/python3.6/contextlib.py", line 81, in __enter__
          return next(self.gen)
        File "/usr/local/lib/python3.6/site-packages/pip/_internal/req/req_tracker.py", line 94, in track
          self.add(req)
        File "/usr/local/lib/python3.6/site-packages/pip/_internal/req/req_tracker.py", line 63, in add
          % (link, fp.read()))
      LookupError: https://files.pythonhosted.org/packages/15/39/728ccb81172c73f14084948b2d4561d5e51649dcf4b21d1f207b7363b1d7/wheel-0.34.0.tar.gz#sha256=a69231973dccde8558f80f2ef058335a1d0bc1b55b2a5a2dfb5097e151e3c498 (from https://pypi.org/simple/wheel/) (requires-python:!=3.0.*,!=3.1.*,!=3.2.*,!=3.3.*,!=3.4.*,>=2.7) is already being built: wheel from https://files.pythonhosted.org/packages/15/39/728ccb81172c73f14084948b2d4561d5e51649dcf4b21d1f207b7363b1d7/wheel-0.34.0.tar.gz#sha256=a69231973dccde8558f80f2ef058335a1d0bc1b55b2a5a2dfb5097e151e3c498

For our project, built wheel file [ via command: python -m build] for latest python version 3.11 for linux, mac and windows. I was able to create source distribution and built distribution under dist of the respective platform.

I wanted to upload them in testpypi having different wheel package for different platform. And I tried this on windows having these wheels in windows. Getting the error as: Binary wheel has an unsupported platform tag 'linux_x86_64'

I request you to share info in release process for a package.

Following on from #485, this expands on the tests added in https://github.com/pypa/wheel/commit/44193907eb308930de05deed863fb4d157c5c866 to include more variations and, more importantly, tests the returned group portions of the regex

This commit hook was causing me some issues. Since I use autoclrf I don't upload mixed line endings on commits even without a hook preventing it, but that's a local setting.

A .gitattributes file enforces line endings regardless of local settings. This does what this commit hook was intending to do but works better across platforms.

Note that this issue is related to https://github.com/pypa/wheel/issues/171 .

When building a wheel with "python -m build --wheel" on Windows, it ends up executing wheel/bdist_wheel.py, and outputs this warning to screen:

C:\temp\build-env-wi_m8kpm\lib\site-packages\wheel\bdist_wheel.py:80: RuntimeWarning: Config variable 'Py_DEBUG' is unset, Python ABI tag may be incorrect
  if get_flag('Py_DEBUG',

This is because wheel/src/wheel/bdist_wheel.py has a local implementation of get_abi_tag() that's called by bdist_wheel.get_tag(), which is called by bdist_wheel.run(). This local implementation isn't able to detect the debug attribute properly on Windows, so it issues a warning.

But wheel/src/wheel/vendored/packaging/tags.py has another implementation of this functionality in _cpython_abis() that detects the debug attribute more correctly:

    debug = pymalloc = ucs4 = ""
    with_debug = _get_config_var("Py_DEBUG", warn)
    has_refcount = hasattr(sys, "gettotalrefcount")
    # Windows doesn't set Py_DEBUG, so checking for support of debug-compiled
    # extension modules is the best option.
    # https://github.com/pypa/pip/issues/3383#issuecomment-173267692
    has_ext = "_d.pyd" in EXTENSION_SUFFIXES
    if with_debug or (with_debug is None and (has_refcount or has_ext)):
        debug = "d"

tags._cpython_abis() is called by tags.cpython_tags(), which is called by tags.sys_tags(). See https://github.com/pypa/packaging/issues/194 and https://github.com/pypa/packaging/issues/172 for the relevant recent work that improved this debug attribute detection on Windows.

wheel/src/wheel/bdist_wheel.py already has:

from .vendored.packaging import tags

...and uses tags.interpreter_name(), tags.interpreter_version(), and tags.sys_tags(). So it seems like using the tags module a little more extensively should be safe, as long as it gives the same behavior on all Python versions still supported by wheel (>=3.7 according to wheel/setup.py).

It seems to me that the local implementation of get_abi_tag() could be replaced with an appropriate call to tags.sys_tags(), and get_abi_tag() could be removed. The current code does:

            impl_name = tags.interpreter_name()
            impl_ver = tags.interpreter_version()
            impl = impl_name + impl_ver
            # We don't work on CPython 3.1, 3.0.
            if self.py_limited_api and (impl_name + impl_ver).startswith("cp3"):
                impl = self.py_limited_api
                abi_tag = "abi3"
            else:
                abi_tag = str(get_abi_tag()).lower()
            tag = (impl, abi_tag, plat_name)

...where I could imagine it instead doing:

            impl_name = tags.interpreter_name()
            impl_ver = tags.interpreter_version()
            impl = impl_name + impl_ver
            # We don't work on CPython 3.1, 3.0.
            if self.py_limited_api and (impl_name + impl_ver).startswith("cp3"):
                impl = self.py_limited_api
                abi_tag = "abi3"
                tag = (impl, abi_tag, plat_name)
            else:
                tag = tags.sys_tags()[0]

If this isn't feasible for some reason, another option would be to change the local implementation of get_abi_tag() to imitate the relevant packaging.tags._cpython_abis() code that detects the debug and with_pymalloc attributes, with a particular care not to warn on Windows in an expected situation that is immediately going to be rectified by an appropriate alternate detection mechanism. This is more complicated, so I won't attempt to suggest the exact patch for this option.