-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Could not find setuptools>=40.8.0 (with Setuptools installed) #12050
Comments
So, you're installing setuptools in your current environment. Then you're installing the current project with You can avoid this by using I agree that the error reporting isn't ideal. PRs to improve this would, of course, be welcome. |
When running In addition, running Arch, pip 23.1.2, and python 3.11.3. |
@tilktilk5 pleas provide the full error, you've left out the important information to which package is causing this error. |
pip 22.3.1 encountered this issue when installing imgviz 1.7.3 in offline mode, too. Using win-10 python 3.10.9. |
That statement doesn't match with what's going on with the workaround. The only difference between the execution that fails and the one that succeeds is additionally supplying wheel. I realize the usage of
Attempting to install without setuptools results in the error.
Even installing Setuptools doesn't work around the error and results in the same error message.
But, installing
My guess is that pip has some logic that falls back from isolated builds when both setuptools and wheel are present.
Indeed, uninstalling wheel and then running with
I acknowledge that I'm holding it wrong, but I'm a seasoned user in the packaging ecosystem and I'm struggling to understand how to hold it right. Maybe it would help if pip were to emit which build technique it's using ("attempting isolated build (requires dependencies to be installable)..." and "attempting fallback non-isolated build (detected setuptools and wheel available)" and "not attempting fallback non-isolated build (one or more of setuptools and wheel unavailable)"), possibly also with reference to directions as to what that technique does and how to address common issues with that technique or to aid pip in using a preferable technique. Note also that the "fix" for the pip-run issue was to add setuptools and wheel to the test environment. Perhaps a more robust fix would be to update the package under test to define a "pyproject.toml" instead of a setup.py. |
This does not work. It's clear that pip does not need setuptools since installing wheel alone is sufficient. It's also not clear that it even needs wheel, since it can somehow manage "Building wheels for collected packages: wheel" without having an existential crisis. See here for more information. I don't think it's too much to ask that |
It is. Build time dependencies need to be pulled in from somewhere to be able to build the package. |
This is not a build time dependency. This is a core functionality of a package manager. I can do |
No, it is not.
You can still do that, as long as you have a built distribution file (i.e. a |
I do this on @tilktilk5's behalf, since I have the same issue:
I am not familiar with Python's own packaging; I use Arch Linux packages whenever possible. I have the Arch Linux package Regards! |
The I suspect you are using the PyTorch index incorrectly - you should probably re-read their installation instructions, and maybe ask for help on their forums. Maybe you were meant to use
This won't help, as pip builds packages in an isolated build environment, and so needs to download and install the build backend (setuptools in this case) regardless of whether you have it available in your system environment. |
FYI, users should be aware Likely the user is using a Python version not supported by PyTorch for that specific local build type, as you say they should check with PyTorch what is supported (installation instructions, help community, etc.). |
I'm using Arch just as @dreirund and I'm seeing following output:
Not sure if this is an issue with pip, python-setuptools, arch or stable-diffusion-webui Also, the message |
@dreirund @tilktilk5
In my case, the |
Yes, dependencies across two indexes is not well supported in the Python packaging ecosystem right now. With Pip the only secure way is to run it across two different install commands, one against each index. My understanding is PEP 708 will help here, as one index will be able to specify getting a package from a different index, but I am not sure if there are some nuances that might cause issues in practise for this example, and supportting it by any package installer is currently blocked until PyPI implements this feature. |
Current PyTorch instructions don't work out of the box because the `lit` package doesn't exist in the `cu118` index. Installing `lit` in a previous step solves the issue. See pypa/pip#12050 (comment) for more details.
Description
In jaraco/pip-run#73, I was investigating an issue surfaced by the removal of setuptools/wheel by default from virtualenv on Python 3.12. While troubleshooting, I added Setuptools as a dependency (jaraco/pip-run@d6783ea), but the error persisted:
The test that's failing is simply building a legacy Setuptools project (
setup.py
, nopyproject.toml
). It's failing to find Setuptools presumably because the tests are passing--no-index
.This error is confusing in a couple of ways:
Expected behavior
Ideally, pip shouldn't try to install setuptools if it's installed and satisfied. If it needs wheel and/or setuptools to do the build but it doesn't have one, it should state as much ("installing implied {setuptools or wheel} for legacy build"), and then only attempt to install the missing package.
Separately, it's apparent that the subprocess boundary isn't a good indicator of which project might be responsible. Better would be for pip to indicate which builder was used and maybe which project might be responsible (maybe).
pip version
23.3.1
Python version
3.12.0a7
OS
any
How to Reproduce
With setuptools/wheel uninstalled:
Note the build succeeds if wheel is present:
Output
No response
Code of Conduct
The text was updated successfully, but these errors were encountered: