Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"wheel convert" depends on setuptools #510

Open
SpecLad opened this issue Mar 10, 2023 · 27 comments · May be fixed by #577
Open

"wheel convert" depends on setuptools #510

SpecLad opened this issue Mar 10, 2023 · 27 comments · May be fixed by #577

Comments

@SpecLad
Copy link

SpecLad commented Mar 10, 2023

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'
@henryiii
Copy link
Contributor

henryiii commented Mar 12, 2023

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. :)

@henryiii
Copy link
Contributor

Oh, convert only converts eggs to wheels? Are there still eggs around to convert? Looks like all the other commands are fine.

@agronholm
Copy link
Contributor

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.

@henryiii
Copy link
Contributor

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.

@agronholm
Copy link
Contributor

My quick assessment is that they don't really need setuptools since all they do is convert the metadata and repackage the files.

@nanonyme
Copy link

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.

@nanonyme
Copy link

This is a blocker for release with flit, right?

@henryiii
Copy link
Contributor

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!

@SpecLad
Copy link
Author

SpecLad commented Mar 13, 2023

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.

@nanonyme
Copy link

@henryiii indeed wheel is a build dependency of setuptools.

@agronholm
Copy link
Contributor

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.

@nanonyme
Copy link

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.

@henryiii
Copy link
Contributor

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. :)

@nanonyme
Copy link

Yeah, I think seems probable that it's a side-effect of something that the stable release didn't fail for @SpecLad

@henryiii
Copy link
Contributor

henryiii commented Mar 13, 2023

Yep, before 0de0c1a 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)

@SpecLad
Copy link
Author

SpecLad commented Mar 13, 2023

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.

@agronholm
Copy link
Contributor

It did briefly have that, but I had to backtrack quickly as it caused all sorts of issues.

@amberkushwaha
Copy link

the file format blogging is done in it with the git_hub module telecasting.also the branch issue has also been resolved in it.

@dholth
Copy link
Member

dholth commented Oct 17, 2023

This entire project is a setuptools plugin? AFAICT other wheel generators like flit or enscons avoid using the wheel package.

@henryiii
Copy link
Contributor

henryiii commented Oct 17, 2023

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 (pypa/setuptools#3908). The CLI already is not a setuptools plugin.

(And depending on setuptools can cause causes weird circular dependency issues)

@nanonyme
Copy link

This package absolutely cannot be used by flit or build without hitting circular dependencies.

@nanonyme
Copy link

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

@dholth
Copy link
Member

dholth commented Oct 17, 2023

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.

@henryiii
Copy link
Contributor

henryiii commented Oct 17, 2023

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?

@dholth
Copy link
Member

dholth commented Oct 17, 2023

wheel[convert] sounds reasonable and harmless. egg is a setuptools format after all.

@henryiii
Copy link
Contributor

.egg is a very deprecated setuptools format. It hasn't been supported by pip for at least a year, AFAICK?

@nanonyme
Copy link

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.

@henryiii henryiii linked a pull request Oct 17, 2023 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants