v0.46.0 Breaking CI build pipelines #660

fervand1 · 2025-04-03T12:38:09Z

Summary

The latest release v0.46.0 is breaking the pipelines which were previously working. The following error is raised.

      [stderr]
      error: invalid command 'bdist_wheel'

      hint: This error likely indicates that `mypackage @ file:///D:/test/myrepo/mypackage`
      depends on `wheel`, but doesn't declare it as a build dependency. If `mypackage @
      file:///D:/test/myrepo/mypackage` is a first-party package, consider adding `wheel` to
      its `build-system.requires`. Otherwise, `uv pip install wheel` into the environment and re-run with
      `--no-build-isolation`.

Although wheel is not the direct dependency, I have following configuration, where wheel is dependency of mybuildtools package.

[build-system]
requires = ["setuptools", "mybuildtools"]
build-backend = "setuptools.build_meta"

What has changed in the new release that is causing the issue and why it needs to be explicit dependency and not sub dependency? I think the previous version was doing it correctly.

Note: If I downgrade to v0.45.0, the pipelines are succeeding correctly

Platform

Windows 11

Version

v0.46.0

Python version

3.10

The text was updated successfully, but these errors were encountered:

agronholm · 2025-04-03T12:39:49Z

Duplicate, and already resolved by yanking the release.

agronholm · 2025-04-03T12:41:06Z

Hm, I am now wondering if this is truly a duplicate.

agronholm · 2025-04-03T12:43:09Z

I see that your build requirements don't specify a minimum version, so it could be using a old setuptools version from cache that doesn't vendor bdist_wheel. Updating it to specify setuptools >= 70.1 should resolve any problems going forward.

agronholm · 2025-04-03T12:55:33Z

Is mybuildtools your own thing? What does its pyproject.toml looks like? Remember that wheel doesn't have a public API, so importing it is a bad idea.

fervand1 · 2025-04-03T13:05:25Z

@agronholm Hi yes it is a inhouse build library

pyproject.toml just looks like that

[build-system]
requires = ["setuptools"]
build-backend = "setuptools.build_meta"

[tool.black]
line-length = 120
skip-string-normalization = true

[tool.isort]
multi_line_output = 3

[tool.flake8]
max-line-length = 132

[tool.pycodestyle]
max-line-length = 132

But we are still maintaining compatibility with python 2 for some of our work so we also have setup.cfg which lists other dependencies see below. I see setuptools was listed to be > 65.

[metadata]
name = mybuildtools
version = 3.0.0

[options]
package_dir =
     = src
packages = find:
zip_safe = False
install_requires =
    setuptools; python_version=='2.7'
    setuptools>65; python_version >= '3.9'
    wheel
    jinja2
    jsonschema
    pathlib; python_version=='2.7'
    pytest<5; python_version == '2.7'
    pytest; python_version >= '3.9'
    six
    uv; python_version >= '3.9'
include_package_data = True

fervand1 · 2025-04-03T13:07:05Z

@agronholm is it possible to get the whl file of the yanked version 0.46.0 ? I could test it by trying your suggestion of listing setuptools>=70.1 . I can no longer install it with pip command

agronholm · 2025-04-03T13:07:26Z

@agronholm is it possible to get the whl file of the yanked version 0.46.0 ? I could test it by trying your suggestion of listing setuptools>=70.1 . I can no longer install it with pip command

You can just depend on wheel==0.46.0.

agronholm · 2025-04-03T13:08:51Z

@agronholm is it possible to get the whl file of the yanked version 0.46.0 ? I could test it by trying your suggestion of listing setuptools>=70.1 . I can no longer install it with pip command

You can just depend on wheel==0.46.0.

Due to this, that won't work either.

fervand1 · 2025-04-03T13:44:08Z

@agronholm FYI, I did the following steps

pip install wheel==0.46.0
In setup.cfg, setuptools>=70.1; python_version >= '3.9'
Installed mybuildtools, which pulled latest setuptools v78
Ran installation commands, and it worked

To reproduce again,

uninstalled setuptools
Installed older version of setuptools I had on the system 65.5.0
Reset setup.cfg, setuptools>65; python_version >= '3.9'
Installed mybuildtools, it didn't pull new version this time as requirement was satisfied
Ran installation commands, and it reproduced.

So suggestion of setting setuptools>=70.1 works

agronholm · 2025-04-03T13:45:57Z

I'm confused. Can you clarify which version of setuptools was actually installed? There's a range of versions which would actually work, but the latest release shouldn't.

fervand1 · 2025-04-03T13:48:21Z

setuptools version 78.1.0

fervand1 · 2025-04-03T13:52:55Z

@agronholm Double checked. Upgraded just the setuptools in the venv. It took 78.1.0. Error was gone

agronholm · 2025-04-03T13:55:03Z

OK, but that also means it will not use wheel v0.46.0 because it's yanked, right?

agronholm · 2025-04-03T13:56:13Z

Due to isolated builds, the wheel version in your current venv would not be used, but an isolated venv would be created for any build process. You can opt out of this with the --no-build-isolation pip option.

fervand1 · 2025-04-03T14:01:45Z

@agronholm oh yes you right. The isolated build environment might have picked the lower version. Yes in that case it will still impact.

fervand1 · 2025-04-03T14:38:00Z

@agronholm I re-verified. Turns out the mybuildtools library we have already uses --no-build-isolation in its custom install commands. I executed the command with the flag set for demonstration. So wheel is actually the version I have in the venv. And am able to reproduce the error just by downgrading setuptools to 65.5.0 and when I upgrade to 78.1, it seems to work. Wheel version in env 0.46.0. I am pasting raw terminal output for your reference.

myrepo on  main via  v3.10.11 (venv)
  ❯ pip install --upgrade setuptools
Looking in indexes: https://__token__:****@gitlab.com/api/v4/groups/xxxx/-/packages/pypi/simple, https://pypi.org/simple
Requirement already satisfied: setuptools in d:\test\myrepo\venv\lib\site-packages (65.5.0)
Collecting setuptools
  Using cached setuptools-78.1.0-py3-none-any.whl.metadata (6.6 kB)
Using cached setuptools-78.1.0-py3-none-any.whl (1.3 MB)
Installing collected packages: setuptools
  Attempting uninstall: setuptools
    Found existing installation: setuptools 65.5.0
    Uninstalling setuptools-65.5.0:
      Successfully uninstalled setuptools-65.5.0
Successfully installed setuptools-78.1.0

myrepo on  main via  v3.10.11 (venv) took 4s
  ❯ python -m uv pip install --no-build-isolation -e mypackage
Using Python 3.10.11 environment at: venv
Resolved 36 packages in 5.89s
      Built mypackage @ file:///D:/test/myrepo/mypackage
Prepared 1 package in 970ms
Uninstalled 1 package in 2ms
░░░░░░░░░░░░░░░░░░░░ [0/1] Installing wheels...                                                                         warning: Failed to hardlink files; falling back to full copy. This may lead to degraded performance.
         If the cache and target directories are on different filesystems, hardlinking may not be supported.
         If this is intentional, set `export UV_LINK_MODE=copy` or use `--link-mode=copy` to suppress this warning.
Installed 1 package in 13ms
 ~ mypackage==3.2513.999999.dev0 (from file:///D:/test/myrepo/mypackage)

agronholm · 2025-04-03T14:41:06Z

Oh, right. The problem with the latest setuptools was constrained to macOS, and you're running Windows. Sorry for not noticing before!

fervand1 · 2025-04-03T14:43:11Z

@agronholm yes no problem

fervand1 · 2025-04-03T14:45:20Z

@agronholm
The error hint is still odd, why would it ask to re-run with --no-build-isolation when its already running with it?

      hint: This error likely indicates that `mypackage @ file:///D:/test/myrepo/mypackage`
      depends on `wheel`, but doesn't declare it as a build dependency. If `mypackage @
      file:///D:/test/myrepo/mypackage` is a first-party package, consider adding `wheel` to
      its `build-system.requires`. Otherwise, `uv pip install wheel` into the environment and re-run with
      `--no-build-isolation`.

this is with setuptools 65.5.0

agronholm · 2025-04-03T14:53:42Z

This error message likely comes from uv as I've never seen it before.

iXce · 2025-04-03T16:51:45Z

@agronholm FYI, I did the following steps

pip install wheel==0.46.0

In setup.cfg, setuptools>=70.1; python_version >= '3.9'

Installed mybuildtools, which pulled latest setuptools v78

Ran installation commands, and it worked

To reproduce again,

uninstalled setuptools

Installed older version of setuptools I had on the system 65.5.0

Reset setup.cfg, setuptools>65; python_version >= '3.9'

Installed mybuildtools, it didn't pull new version this time as requirement was satisfied

Ran installation commands, and it reproduced.

So suggestion of setting setuptools>=70.1 works

can wheel be made to depend on setuptools>=70.1 or does that create more dependency resolution headaches? (like, it doesn't really depend on setuptools, it's just that wheel used to provide functionality that setuptools can now provide instead)

agronholm · 2025-04-03T19:06:24Z

I thought of that, but I really don't want to do it. As you said, it would probably just replace one problem with a bunch of others. Plus it doesn't help with the macOS issue given how vendoring in setuptools works.

Wheel package released 8th of April (0.46.1) broke installation of sdist-only packages (such as pyspark) in our main images. After investigation, it turned out that this is a combination of things: * The new wheel package does not inject `bdist_wheel` command to setuptools any more. This is because setuptools > 70.1 have the bdist_wheel command vendored in and they do not need wheel at all to build the wheels. * Python official bookworm-slim images that we use as base images - includingthe latest versions released today - have old and sometimes inconsistent version of wheel and setuptools: Python 3.9: wheel: 0.45.1, setuptools: 58.1.0 Python 3.10: wheel: 0.46.1, setuptools: 65.5.1 Python 3.11: wheel: 0.46.1, setuptools: 65.5.1 Python 3.12: no wheel, no setuptools This means that there are the following scenarios that trigger the error that `bdist_wheel` command is missing: * Python 3.9 -> upgrading wheel (Which we did accidentally by other package) and not upgrading setuptools -> error * Python 3.10, 3.11 -> just `pip install pyspark` -> error * Python 3.12 -> all good, latest setuptools would be installed, no wheel needed As a remediation, we are upgrading setuptools to latest released version in our images. We also fix them - similarly to `pip` and `uv` in order to protect against any cases where just upgrading to new setuptools might break thigns (As it happened recently where setuptools upgrade suddenly broke a lot of sdist packages) Our automated pre-commits upgrading installers have been modified to also upgrade setuptools. See pypa/wheel#660 (comment) for details

potiuk · 2025-04-09T06:45:27Z

Also just worth noting - the Python images have been updated 2 hours ago -> so they already contain latest wheel (3.10 and 3.11) but they still contain the old setuptools - and this is something that will likely cause some quite big waves if this is not fixed in those images.

I opened an issue in docker-library/python#1023 but I am not sure who and how manages the official images, but hopefully PyPA team might reach out directly to those who release the images.

…48989) Wheel package released 8th of April (0.46.1) broke installation of sdist-only packages (such as pyspark) in our main images. After investigation, it turned out that this is a combination of things: * The new wheel package does not inject `bdist_wheel` command to setuptools any more. This is because setuptools > 70.1 have the bdist_wheel command vendored in and they do not need wheel at all to build the wheels. * Python official bookworm-slim images that we use as base images - includingthe latest versions released today - have old and sometimes inconsistent version of wheel and setuptools: Python 3.9: wheel: 0.45.1, setuptools: 58.1.0 Python 3.10: wheel: 0.46.1, setuptools: 65.5.1 Python 3.11: wheel: 0.46.1, setuptools: 65.5.1 Python 3.12: no wheel, no setuptools This means that there are the following scenarios that trigger the error that `bdist_wheel` command is missing: * Python 3.9 -> upgrading wheel (Which we did accidentally by other package) and not upgrading setuptools -> error * Python 3.10, 3.11 -> just `pip install pyspark` -> error * Python 3.12 -> all good, latest setuptools would be installed, no wheel needed As a remediation, we are upgrading setuptools to latest released version in our images. We also fix them - similarly to `pip` and `uv` in order to protect against any cases where just upgrading to new setuptools might break thigns (As it happened recently where setuptools upgrade suddenly broke a lot of sdist packages) Our automated pre-commits upgrading installers have been modified to also upgrade setuptools. See pypa/wheel#660 (comment) for details

geminixiang · 2025-04-09T07:12:36Z

Temporarily locking wheel to version 0.45.1 in Doerfile is the best solution for me.

Update: only lock wheel version can fix my CI

potiuk · 2025-04-09T07:24:04Z

I can also confirm (see my PR) that simply adding a separate step where you upgrade to latest setuptools also works well (and will not require reversing later -no matter what wheel maintainers or Official Python image maintainers will do.

apache/airflow#48989

geminixiang · 2025-04-09T07:49:56Z

I can also confirm (see my PR) that simply adding a separate step where you upgrade to latest setuptools also works well (and will not require reversing later -no matter what wheel maintainers or Official Python image maintainers will do.

apache/airflow#48989

I agree with you.

in docker image python:3.11-slim: source code

wheel: 0.46.1
setuptools: 65.5.1 (latest: 78.1.0)

The bdist_wheel command was added to setuptools in v70.1.0，pypa/setuptools#4369

❯ docker run -it python:3.11-slim bash

root@353b0b8d0623:/# pip show wheel
Name: wheel
Version: 0.46.1
Summary: Command line tool for manipulating wheel files
Home-page: 
Author: 
Author-email: Daniel Holth <[email protected]>
License: 
Location: /usr/local/lib/python3.11/site-packages
Requires: packaging
Required-by: 

root@353b0b8d0623:/# pip show setuptools
Name: setuptools
Version: 65.5.1
Summary: Easily download, build, install, upgrade, and uninstall Python packages
Home-page: https://github.com/pypa/setuptools
Author: Python Packaging Authority
Author-email: [email protected]
License: 
Location: /usr/local/lib/python3.11/site-packages
Requires: 
Required-by:

bkumar-sudheer · 2025-04-09T09:16:08Z

I can also confirm (see my PR) that simply adding a separate step where you upgrade to latest setuptools also works well (and will not require reversing later -no matter what wheel maintainers or Official Python image maintainers will do.
apache/airflow#48989

I agree with you.

in docker image python:3.11-slim

wheel: 0.46.1

setuptools: 65.5.1 (latest: 78.1.0)

The bdist_wheel command was added to setuptools in v70.1.0，pypa/setuptools#4369
❯ docker run -it python:3.11-slim bash

root@353b0b8d0623:/# pip show wheel
Name: wheel
Version: 0.46.1
Summary: Command line tool for manipulating wheel files
Home-page: 
Author: 
Author-email: Daniel Holth <[email protected]>
License: 
Location: /usr/local/lib/python3.11/site-packages
Requires: packaging
Required-by: 

root@353b0b8d0623:/# pip show setuptools
Name: setuptools
Version: 65.5.1
Summary: Easily download, build, install, upgrade, and uninstall Python packages
Home-page: https://github.com/pypa/setuptools
Author: Python Packaging Authority
Author-email: [email protected]
License: 
Location: /usr/local/lib/python3.11/site-packages
Requires: 
Required-by: 

I am using same python image. Could you please lmk what fixed the issue for you ?

There is an issue with the 0.46.0 `wheel` version as reported in pypa/wheel#660. We are currently seeing this on the Python packaging pipelines, for example in [this run](https://aiinfra.visualstudio.com/Lotus/_build/results?buildId=740997&view=logs&j=4864752d-f1c3-57c0-06eb-25cee39385a7&s=3fc0883b-27ef-5aa3-1052-0a269c26624c&t=fa95d49e-17f6-501e-c36c-b2949c11fc4a&l=13).

fervand1 · 2025-04-09T09:30:25Z

Just posting summary of resolutions which worked for us for reference

For a package: Pin setuptools >=70.1 in package build requirements.
For CI pipelines: Add a step in CI to upgrade setuptools with python -m pip install --upgrade setuptools.
In case you don't want to update the CI steps but have a custom image, update the image to have latest setuptools.

Hope that helps. Thanks

- `wheel` version 0.46+ now requires `setuptools` version 70 or newer - discussed upstream here: pypa/wheel#660 - discovered in termux-packages here: termux#24062 (comment) - I have confirmed that this change works to fix the build of `python-lxml` **both** - **in `TERMUX_ON_DEVICE_BUILD=false` mode (broken for 1 week)**, - fixes `error: invalid command 'bdist_wheel'` - **and also in `TERMUX_ON_DEVICE_BUILD=true` mode (broken for 6 months)**. - fixes `ModuleNotFoundError: No module named 'setuptools'` - It seems appropriate to remove the `if [ "${TERMUX_PYTHON_VERSION#*.}" -lt "12" ]` block because there is no longer any `python3.11` so it does not seem like that code is reachable anymore. - `python-torchvision` needed ajustment of its custom `CFLAGS` to be `CXXFLAGS` instead, because the newer `setuptools` is now compiling it using `aarch64-linux-android-clang++` instead of `aarch64-linux-android-clang`. - `python-pip` and `python-pillow` both had locked `setuptools` in their `TERMUX_PKG_PYTHON_COMMON_DEPS` at versions slightly newer than the old global version, now that the global version is newer than either of those, they do not seem to need that anymore.

notatallshaw · 2025-04-09T11:20:21Z

Official Python image maintainers will do.

It should be noted that while Docker uses the term "Official" it's a community run image independent of any core Python organization (PSF, PyPA, etc.): https://github.com/docker-library/python?tab=readme-ov-file#httpsgithubcomdocker-librarypython

geminixiang · 2025-04-09T11:36:54Z

I can also confirm (see my PR) that simply adding a separate step where you upgrade to latest setuptools also works well (and will not require reversing later -no matter what wheel maintainers or Official Python image maintainers will do.
apache/airflow#48989

I agree with you.
in docker image python:3.11-slim

wheel: 0.46.1

setuptools: 65.5.1 (latest: 78.1.0)

The bdist_wheel command was added to setuptools in v70.1.0，pypa/setuptools#4369
❯ docker run -it python:3.11-slim bash

root@353b0b8d0623:/# pip show wheel
Name: wheel
Version: 0.46.1
Summary: Command line tool for manipulating wheel files
Home-page: 
Author: 
Author-email: Daniel Holth <[email protected]>
License: 
Location: /usr/local/lib/python3.11/site-packages
Requires: packaging
Required-by: 

root@353b0b8d0623:/# pip show setuptools
Name: setuptools
Version: 65.5.1
Summary: Easily download, build, install, upgrade, and uninstall Python packages
Home-page: https://github.com/pypa/setuptools
Author: Python Packaging Authority
Author-email: [email protected]
License: 
Location: /usr/local/lib/python3.11/site-packages
Requires: 
Required-by: 
I am using same python image. Could you please lmk what fixed the issue for you ?

sample Dockerfile

FROM python:3.11-slim

COPY ./requirements.txt /

# add this line
RUN pip3 install wheel==0.45.1
RUN pip3 install -r requirements.txt

I don't like it, but it works.

and... source issue is in these codes: https://github.com/docker-library/python/blob/f3c69c5acce909a76e287ef1adf8f10c476eb2f0/3.11/bookworm/Dockerfile#L94-L99

agronholm · 2025-04-09T12:12:31Z

I'm closing this in favor of docker-library/official-images#662 where the majority of the debugging conversation is happening.

There is an issue with the 0.46.0 `wheel` version as reported in pypa/wheel#660. We are currently seeing this on the Python packaging pipelines, for example in [this run](https://aiinfra.visualstudio.com/Lotus/_build/results?buildId=740997&view=logs&j=4864752d-f1c3-57c0-06eb-25cee39385a7&s=3fc0883b-27ef-5aa3-1052-0a269c26624c&t=fa95d49e-17f6-501e-c36c-b2949c11fc4a&l=13).

xref: pypa/wheel#660  ## Summary by CodeRabbit - **Chores** - Enhanced the testing setup to ensure key dependencies are kept up-to-date during the test process.  Signed-off-by: Jinzhe Zeng <[email protected]>

- `wheel` version 0.46+ now requires `setuptools` version 70 or newer - discussed upstream here: pypa/wheel#660 - discovered in termux-packages here: termux#24062 (comment) - Lock `wheel` version at 0.46.1 so that if a future `wheel` update causes a similar problem in the future, it doesn't immediately propagate into termux-packages without us explicitly bumping it. Recommended by Tomjo2000 here: termux#24062 (comment) - I have confirmed that this change works to fix the build of `python-lxml` **both** - **in `TERMUX_ON_DEVICE_BUILD=false` mode (broken temporarily for 1 week)**, - fixes `error: invalid command 'bdist_wheel'` - **and also in `TERMUX_ON_DEVICE_BUILD=true` mode (broken for 6 months)**. - fixes `ModuleNotFoundError: No module named 'setuptools'` - It seems appropriate to remove the `if [ "${TERMUX_PYTHON_VERSION#*.}" -lt "12" ]` block because there is no longer any `python3.11` so it does not seem like that code is reachable anymore. - `python-torchvision` needed ajustment of its custom `CFLAGS` to be `CXXFLAGS` instead, because the newer `setuptools` is now compiling it using `aarch64-linux-android-clang++` instead of `aarch64-linux-android-clang`. - `python-pip` and `python-pillow` both had locked `setuptools` in their `TERMUX_PKG_PYTHON_COMMON_DEPS` at versions slightly newer than the old global version, now that the global version is newer than either of those, they do not seem to need that anymore.

… wheel 0.46.1 - `wheel` version 0.46+ now requires `setuptools` version 70 or newer - discussed upstream here: pypa/wheel#660 - discovered in termux-packages here: termux#24062 (comment) - Lock `wheel` version at 0.46.1 so that if a future `wheel` update causes a similar problem in the future, it doesn't immediately propagate into termux-packages without us explicitly bumping it. Recommended by Tomjo2000 here: termux#24062 (comment) - I have confirmed that this change works to fix the build of `python-lxml` **both** - **in `TERMUX_ON_DEVICE_BUILD=false` mode (broken temporarily for 1 week)**, - fixes `error: invalid command 'bdist_wheel'` - **and also in `TERMUX_ON_DEVICE_BUILD=true` mode (broken for 6 months)**. - fixes `ModuleNotFoundError: No module named 'setuptools'` - It seems appropriate to remove the `if [ "${TERMUX_PYTHON_VERSION#*.}" -lt "12" ]` block because there is no longer any `python3.11` so it does not seem like that code is reachable anymore. - `python-torchvision` needed ajustment of its custom `CFLAGS` to be `CXXFLAGS` instead, because the newer `setuptools` is now compiling it using `aarch64-linux-android-clang++` instead of `aarch64-linux-android-clang`. - `python-pip` and `python-pillow` both had locked `setuptools` in their `TERMUX_PKG_PYTHON_COMMON_DEPS` at versions slightly newer than the old global version, now that the global version is newer than either of those, they do not seem to need that anymore.

… wheel 0.46.1 (#24213) - `wheel` version 0.46+ now requires `setuptools` version 70 or newer - discussed upstream here: pypa/wheel#660 - discovered in termux-packages here: #24062 (comment) - Lock `wheel` version at 0.46.1 so that if a future `wheel` update causes a similar problem in the future, it doesn't immediately propagate into termux-packages without us explicitly bumping it. Recommended by Tomjo2000 here: #24062 (comment) - I have confirmed that this change works to fix the build of `python-lxml` **both** - **in `TERMUX_ON_DEVICE_BUILD=false` mode (broken temporarily for 1 week)**, - fixes `error: invalid command 'bdist_wheel'` - **and also in `TERMUX_ON_DEVICE_BUILD=true` mode (broken for 6 months)**. - fixes `ModuleNotFoundError: No module named 'setuptools'` - It seems appropriate to remove the `if [ "${TERMUX_PYTHON_VERSION#*.}" -lt "12" ]` block because there is no longer any `python3.11` so it does not seem like that code is reachable anymore. - `python-torchvision` needed ajustment of its custom `CFLAGS` to be `CXXFLAGS` instead, because the newer `setuptools` is now compiling it using `aarch64-linux-android-clang++` instead of `aarch64-linux-android-clang`. - `python-pip` and `python-pillow` both had locked `setuptools` in their `TERMUX_PKG_PYTHON_COMMON_DEPS` at versions slightly newer than the old global version, now that the global version is newer than either of those, they do not seem to need that anymore.

… wheel 0.46.1 (#24213) - `wheel` version 0.46+ now requires `setuptools` version 70 or newer - discussed upstream here: pypa/wheel#660 - discovered in termux-packages here: termux#24062 (comment) - Lock `wheel` version at 0.46.1 so that if a future `wheel` update causes a similar problem in the future, it doesn't immediately propagate into termux-packages without us explicitly bumping it. Recommended by Tomjo2000 here: termux#24062 (comment) - I have confirmed that this change works to fix the build of `python-lxml` **both** - **in `TERMUX_ON_DEVICE_BUILD=false` mode (broken temporarily for 1 week)**, - fixes `error: invalid command 'bdist_wheel'` - **and also in `TERMUX_ON_DEVICE_BUILD=true` mode (broken for 6 months)**. - fixes `ModuleNotFoundError: No module named 'setuptools'` - It seems appropriate to remove the `if [ "${TERMUX_PYTHON_VERSION#*.}" -lt "12" ]` block because there is no longer any `python3.11` so it does not seem like that code is reachable anymore. - `python-torchvision` needed ajustment of its custom `CFLAGS` to be `CXXFLAGS` instead, because the newer `setuptools` is now compiling it using `aarch64-linux-android-clang++` instead of `aarch64-linux-android-clang`. - `python-pip` and `python-pillow` both had locked `setuptools` in their `TERMUX_PKG_PYTHON_COMMON_DEPS` at versions slightly newer than the old global version, now that the global version is newer than either of those, they do not seem to need that anymore.

agronholm closed this as completed Apr 3, 2025

agronholm reopened this Apr 3, 2025

jdpurcell mentioned this issue Apr 3, 2025

Install QT action fails with "error: invalid command 'bdist_wheel'" jurplel/install-qt-action#281

Open

This was referenced Apr 8, 2025

Pin wheel version to 0.45.1 microsoft/onnxruntime#24347

Closed

Pin wheel version to 0.45.1 microsoft/onnxruntime#24349

Merged

cg505 mentioned this issue Apr 8, 2025

wheel build fails due to dependency issues skypilot-org/skypilot#5153

Open

robertkirkman mentioned this issue Apr 9, 2025

Libxml2 rebuilds: Part 2 - Small packages termux/termux-packages#24062

Merged

38 tasks

midnightveil mentioned this issue Apr 9, 2025

github: pin gitlint in pr workflow to ubuntu 22.04 seL4/ci-actions#402

Closed

potiuk mentioned this issue Apr 9, 2025

Fix issue with setuptools and wheel incompatibility in Python images apache/airflow#48989

Merged

sennierer mentioned this issue Apr 9, 2025

build of apis-instances fails due to setuptools error acdh-oeaw/prosnet-workflows#90

Closed

potiuk mentioned this issue Apr 9, 2025

Python images (At least bookwork-slim) relased today break installation of sdist packages docker-library/python#1023

Closed

This was referenced Apr 9, 2025

Recent 0.6.12 is causing pipeline breaks with error invalid command 'bdist_wheel' astral-sh/uv#12648

Closed

fix(CI): upgrade setuptools to fix its compatibility with wheel deepmodeling/deepmd-kit#4700

Merged

limjcst mentioned this issue Apr 9, 2025

Support complicated use cases with TiedLayerSpec deepspeedai/DeepSpeed#7208

Merged

agronholm closed this as completed Apr 9, 2025

geminixiang mentioned this issue Apr 9, 2025

fix: Upgrade setuptools to 70.1.0+ to support wheel v0.46.0 compatibility docker-library/python#1022

Closed

amarin16 mentioned this issue Apr 9, 2025

Pin wheel version to 0.45.1 (#24349) microsoft/onnxruntime#24367

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

v0.46.0 Breaking CI build pipelines #660

v0.46.0 Breaking CI build pipelines #660

fervand1 commented Apr 3, 2025 •

edited

Loading

agronholm commented Apr 3, 2025

agronholm commented Apr 3, 2025

agronholm commented Apr 3, 2025

agronholm commented Apr 3, 2025

fervand1 commented Apr 3, 2025

fervand1 commented Apr 3, 2025

agronholm commented Apr 3, 2025

agronholm commented Apr 3, 2025

fervand1 commented Apr 3, 2025

agronholm commented Apr 3, 2025

fervand1 commented Apr 3, 2025

fervand1 commented Apr 3, 2025

agronholm commented Apr 3, 2025

agronholm commented Apr 3, 2025

fervand1 commented Apr 3, 2025 •

edited

Loading

fervand1 commented Apr 3, 2025 •

edited

Loading

agronholm commented Apr 3, 2025

fervand1 commented Apr 3, 2025

fervand1 commented Apr 3, 2025 •

edited

Loading

agronholm commented Apr 3, 2025

iXce commented Apr 3, 2025

agronholm commented Apr 3, 2025

potiuk commented Apr 9, 2025 •

edited

Loading

geminixiang commented Apr 9, 2025 •

edited

Loading

potiuk commented Apr 9, 2025 •

edited

Loading

geminixiang commented Apr 9, 2025 •

edited

Loading

bkumar-sudheer commented Apr 9, 2025

fervand1 commented Apr 9, 2025

notatallshaw commented Apr 9, 2025

geminixiang commented Apr 9, 2025 •

edited

Loading

agronholm commented Apr 9, 2025

v0.46.0 Breaking CI build pipelines #660

v0.46.0 Breaking CI build pipelines #660

Comments

fervand1 commented Apr 3, 2025 • edited Loading

Summary

Platform

Version

Python version

agronholm commented Apr 3, 2025

agronholm commented Apr 3, 2025

agronholm commented Apr 3, 2025

agronholm commented Apr 3, 2025

fervand1 commented Apr 3, 2025

fervand1 commented Apr 3, 2025

agronholm commented Apr 3, 2025

agronholm commented Apr 3, 2025

fervand1 commented Apr 3, 2025

agronholm commented Apr 3, 2025

fervand1 commented Apr 3, 2025

fervand1 commented Apr 3, 2025

agronholm commented Apr 3, 2025

agronholm commented Apr 3, 2025

fervand1 commented Apr 3, 2025 • edited Loading

fervand1 commented Apr 3, 2025 • edited Loading

agronholm commented Apr 3, 2025

fervand1 commented Apr 3, 2025

fervand1 commented Apr 3, 2025 • edited Loading

agronholm commented Apr 3, 2025

iXce commented Apr 3, 2025

agronholm commented Apr 3, 2025

potiuk commented Apr 9, 2025 • edited Loading

geminixiang commented Apr 9, 2025 • edited Loading

potiuk commented Apr 9, 2025 • edited Loading

geminixiang commented Apr 9, 2025 • edited Loading

bkumar-sudheer commented Apr 9, 2025

fervand1 commented Apr 9, 2025

notatallshaw commented Apr 9, 2025

geminixiang commented Apr 9, 2025 • edited Loading

agronholm commented Apr 9, 2025

fervand1 commented Apr 3, 2025 •

edited

Loading

fervand1 commented Apr 3, 2025 •

edited

Loading

fervand1 commented Apr 3, 2025 •

edited

Loading

fervand1 commented Apr 3, 2025 •

edited

Loading

potiuk commented Apr 9, 2025 •

edited

Loading

geminixiang commented Apr 9, 2025 •

edited

Loading

potiuk commented Apr 9, 2025 •

edited

Loading

geminixiang commented Apr 9, 2025 •

edited

Loading

geminixiang commented Apr 9, 2025 •

edited

Loading