I opened an issue with auditwheel-emscripten
about the failure that I saw before wheel 0.46.0 was yanked. I am not sure what they are supposed to use instead of wheel.cli instead though. If the suggestion is that they should use the CLI interface rather than attempting to import something that might be more difficult than it sounds because if the wheel package is being used inside pyodide then it is not possible to launch subprocesses.
2 Likes
I yanked until the problem can be solved. At least in some cases I believe this happens where an old version of setuptool has been cached but wheel hasn’t.
I am not sure what they are supposed to use instead of
wheel.cliinstead though.
Perhaps they should’ve reached out to me for a solution instead of just importing a private API?
1 Like
Thanks for the quick response on yanking the release, it was recently discussed about the challenges of backwards compatability being a build backend, but it seems there is even more nuance being a dependency of a build backend.
I am working to try and have pip 24.2 (not the release this month, but the one in July) to emit warnings from the build backend process, so hopefully users will be more aware what to fix.
1 Like
Cross posting for visibility.
There is a discussion regarding the future of macosx_libfile in pypa/setuptools#4935.
Hmm, I see, thanks. Is it possible to add version constraints to wheel and/or setuptools to avoid such incompatible combinations?
Yes, create a build-constraints.txt such as:
setuptools==77.0.3
wheel==0.45.1
For pip, set the env var PIP_CONSTRAINT=build-constraints.txt.
For uv pip you can use the --build-constraint flag or UV_BUILD_CONSTRAINT env var. I am keen on getting the same flag added to pip in the future, and I have suggested that uv could use it’s per package metadata override API for users correct specific packages.
In general a lot of tooling improvements should happen to help users if build backends, and dependencies of build backends, are going to make backwards incompatible changes. Such as warning them and giving them the ability to mitigate risks.
1 Like
No, I mean set those version constraints in the setuptools and/or wheel packages’ metadata themselves.
1 Like
It isn’t really possible to set version constraints in packages that don’t actually depend on each other. The place to put the constraint would need to be in a really old setuptools version that won’t get updated anyway.
There’s currently no way for a project, like wheel, to specify constraints on other packages installed that are not dependencies, or on itself in the presence of other installed packages.
And setuptools has no non-optional dependencies, instead it has made a choice to import wheel when it’s available, but otherwise use a vendored copy, this design choice has made a context sensitive dependency, not described in the non-optional metadata.
2 Likes
I assume that they did not realise it was a private API. In any case there is now a new release of auditwheel-emscripten that runs wheel in a subprocess using its command line interface rather than importing wheel.cli.
2 Likes
It could comes from pip, which still runs setup.py bdist_wheel if both setuptools and wheel are installed, for projects without pyproject.toml. Although I don’t recognize pip output in your log.
I’ve temporarily restored the wheel.macosx_libfile module to prevent macOS builds failing in the next release. Another potential issue is #660 where a user, for whatever reason, only upgraded wheel but not setuptools, leading to a situation where an old version of setuptools doesn’t have the bdist_wheel command. This one is clearly a user error but I don’t know yet what kind of impact it will have.
How should I mitigate the issue and provide a clear understanding of what the problem is? Perhaps I should restore the entry point and have the command simply error out, explaining that their setuptools is out of date?
I assume you don’t have a dependency on setuptools that can have a minimum version? (Just confirmed at the end of the issue - yeah, agree, don’t add one.) There was some discussion somewhere about supporting version constraints in packages, rather than requirements, which would have suited this case fine, but it never actually happened.
Since you’re not getting loaded at all, I’d probably just document this one and let users discover it. Forcing your code to run when it’s currently not being loaded at all is more likely to introduce new issues than it is to help drastically with this one. Either way, the answer is to either pin an earlier wheel or a later setuptools (or stop preferring an old cache over a new release), and people who have customised as much as that OP ought to be able to figure that out (with a doc page stating that newer setuptools is needed and showing the command/error you get if it’s too old).
This would of course be the solution for users, but what I want is to avoid getting flooded with reports like that when users just see no such command: bdist_wheel suddenly appearing in their CI.
Create an issue with that title and pin it. Hopefully some/most people will see it and read it before posting the exact same error as a new issue.
2 Likes
IMO it’s on setuptools to provide a better message when a plugin isn’t available. Of course, that doesn’t really help here, because you can’t go back in time and fix old versions of setuptools 
I’d create a pinned issue in the wheel tracker explaining the problem, and maybe also create a StackOverflow question, and answer it yourself, describing the problem and what the fix is. Those two methods have helped in the past on pip - they don’t completely stop the issue reports, but it’s relatively easy to close them with a boilerplate “Duplicate of #xxx” message.
1 Like
Well, there’s #660 already so I’ll just pin that one.
At least update the title, and you probably want to make the fix really obvious, so you might have to edit the top post to add it in.
1 Like
Yup, v0.46.1 predictably resulted in #662 which I’ve pinned now.
Turns out packages like docplex exist which pin setuptools to ~=68.2.2 in their build requirements in pyproject.toml, so upgrading wheel isn’t going to be helpful, as it gets installed as part of the PEP 517 process.