wheel
wheel copied to clipboard
pypa
"wheel convert" depends on setuptools
~~Since 0de0c1a, wheel no longer declares a runtime dependency on setuptools. However, the convert command still needs setuptools to work.~~ (Never mind this part, there was never a runtime dependency to start with.)
wheel doesn't declare a runtime dependency on setuptools, but the convert command needs it to work. Here's what happens when setuptools is not installed:
> .\venv\Scripts\wheel.exe convert
Traceback (most recent call last):
File "<frozen runpy>", line 198, in _run_module_as_main
File "<frozen runpy>", line 88, in _run_code
File ".\venv\Scripts\wheel.exe\__main__.py", line 7, in <module>
File ".\venv\Lib\site-packages\wheel\cli\__init__.py", line 91, in main
args.func(args)
File ".\venv\Lib\site-packages\wheel\cli\__init__.py", line 29, in convert_f
from .convert import convert
File ".\venv\Lib\site-packages\wheel\cli\convert.py", line 10, in <module>
from ..bdist_wheel import bdist_wheel
File ".\venv\Lib\site-packages\wheel\bdist_wheel.py", line 24, in <module>
import pkg_resources
ModuleNotFoundError: No module named 'pkg_resources'
It also contains the somewhat useless extra lines (AFAICT?):
try:
from setuptools import Distribution
except ImportError:
from distutils.dist import Distribution
Besides distutils going away, from ..bdist_wheel import bdist_wheel right above requires setuptools (or pkg_resources in the current version, same difference)
This is literally the only usage of raw distutils, too. :)
Oh, convert only converts eggs to wheels? Are there still eggs around to convert? Looks like all the other commands are fine.
It converts both .egg and .msi to wheels. I don't know if it's used anymore, since the tool doesn't exactly phone home to report statistics.
A temporary workaround would be to keep the runtime dependency on setuptools for now, and deprecate it. A second possibility would be to add an extra, like [convert], that would add the setuptools dependency. The ideal solution, removing the requirement on setuptools for this command, sounds tricky since I'm assuming eggs and msi conversion will likely touch stuff in setuptools. Though I haven't investigated that much.
My quick assessment is that they don't really need setuptools since all they do is convert the metadata and repackage the files.
I'm not really sure if it would be a problem if this runtime depended on setuptools. Depends on whether pip dep resolver regards it a cycle or not. I think setuptools has some bootstrap magic to discover itself from source tree.
Regardless of resolving, it would be bad if wheel had a public API (#472) that was intended to be used by tools other than setuptools, but still pulled in setuptools. That's a longer term issue, though, which is why I suggested the temporary workaround. I'm a fan of smaller but more frequent changes over a rare "break everyone" release. :) Though, now that you mention it, it might be an issue if setuptools requires wheel, which then gets installed, and therefore pulls it's dependencies, which include setuptools... Yeah, that might be a problem. Runtime dep on setuptools might truly be not an option, even short term.
It doesn't need to be bootstrap magic, self-builds are built into PEP 517. Flit-core builds itself that way.
It would be great, though, if this could be solved properly without setuptools!
FWIW, I don't think convert functionality is needed in the API. It seems like a pretty niche command, and it'll only become less and less relevant as time goes on.
Given how nobody has complained about it requiring setuptools but without wheel declaring it, it seems like it's not getting a lot of use. I'll probably just drop it in the publicapi branch.
I think this may be partially explained by abundant usage of pkg_resources from setuptools by basically everyone which is now getting replaced by importlib.resources. It's possible setuptools has been widely available on platforms where wheel convert has been used but this may stop being the case.
But if it that is the case, it's not a problem of the flit conversion, and is just as present in the current release. :)
Yeah, I think seems probable that it's a side-effect of something that the stable release didn't fail for @SpecLad
Yep, before 0de0c1af8e3bd8cbc813cb79ee6c7f1765088949 there was no runtime dependence on setuptools either. If you were installing wheel from a wheel (most users), there's really no difference before or after the conversion. If you install from SDist, you used to need setuptools in the build environment, and now you don't. But that's the only change. Most environments happen to have setuptools injected, include default venvs, though that may change. pipx likely even gets setuptools since it's built on venv or virtualenv. (Yes, looks like it does)
Yeah, sorry for the confusion. For some reason, I was certain wheel used to have a runtime dependency on setuptools, but I was mistaken. I'll edit the issue description.
It did briefly have that, but I had to backtrack quickly as it caused all sorts of issues.
the file format blogging is done in it with the git_hub module telecasting.also the branch issue has also been resolved in it.
This entire project is a setuptools plugin? AFAICT other wheel generators like flit or enscons avoid using the wheel package.
It's supposed to be slowly becoming a more general package with an API (#472), and setuptools will slowly be integrating the bdist_wheel command (https://github.com/pypa/setuptools/pull/3908). The CLI already is not a setuptools plugin.
(And depending on setuptools can cause causes weird circular dependency issues)
This package absolutely cannot be used by flit or build without hitting circular dependencies.
To be fair, I would just suggest making flit wheel building the canonical thing and merge everything there. The first wheel you will ever build is flit (with itself).
I'm saying I think it should not be a bug that wheel convert depends on setuptools, too bad that the circular depedency causes problems, neat that it might be easy to fix though.
Does any wheel generator depend on the wheel package? Like flit, they tend to generate the wheel file format themselves.
They are not supposed to, since there is no public API in wheel yet. The idea is that they could. flit won't ever pick up dependencies, but others (hatch, etc.) might use wheel if it had a public API. (even import wheel inside setup.py is discouraged!)
You don't need setuptools to run the other commands, though. I don't want to download setuptools if I'm changing the tags on a wheel, packing a wheel, or unpacking a wheel. The only place this is a problem is if you are converting .egg/.msi to wheels, in which case, I think you can install setuptools manually. An extra wheel[convert] or wheel[setuptools] might help?
wheel[convert] sounds reasonable and harmless. egg is a setuptools format after all.
.egg is a very deprecated setuptools format. It hasn't been supported by pip for at least a year, AFAICK?
Setuptools most definitely depends on wheel these days. Even building setuptools with non-legacy backend requires wheel. It seems fine though that wheel convert requires setuptools. Similarly flit-core has less deps than flit.