-
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
Unable to build no-binary :all: with use-pep517 #7831
Comments
I attempted to address this within wheel at pypa/wheel#344, but it seems that even declaring the build dependencies,
I think pip probably should do something here to allow wheel to build when installed from source. |
Is this not related to in-tree backend support (which pip doesn't yet include, IIRC)? I thought the idea of that PEP update was precisely to allow projects to be defined in a way that meant they worked even if the user requested that everything was built from source. If it's not then I think we need to get a much better understanding of what pip is expected to do in the face of |
I believe this issue is unrelated to in-tree backend support, though I do think that support is present in pip 20). The issue may be described thus: Attempting to build any package with It might just be the case that when using pep517 to build a package, it should also use pep517 to build the package's dependencies also... except that
Agreed. Maybe the answer is that |
Eww. Yes, that is a variant of the bootstrapping issue that in-tree backend support was addressing, but sufficiently different to be a new problem in its own right.
That would be my strong preference. I honestly don't see why pip has to be the tool to handle the "build everything from raw source" problem. But there were fairly strong voices arguing that we had to support that case, so I think they should be the ones defining the solution here. |
In my use-case, I wasn't concerned with the "build everything from raw source" use case, but was rather attempting to build a single package from source and I used |
In the referenced vendoring issue, I learned that it's not just system packagers that want to build from source but also packages that wish to verify licenses. |
Coming from ActiveState/appdirs#141,
How about letting |
I think the whole idea of build isolation is to ultimately remove |
Thank you @uranusjr, I totally missed that point. |
chatboat python if you want to install chatterbot pip install chatterbot --no-binary :all: you should use "pip install chatterbot --no-binary :all:" before that run under three codes and install it. conda remove --force PyYAML |
I ran into this issue again today, this time with
Because I'm trying to be a good citizen and operate without
When setuptools tries to build from source, which tries to build wheel from source, and setuptools isn't present.
I tried instead to employ pep517, but that failed similarly:
The only way I know to make it work is to pre-install setuptools (works with or without
|
Is this not the situation that in-tree build backends were designed to address? Does setuptools configure itself as its own in-tree build backend? If not, then maybe it needs to for the |
Environment
Description
As distlib doesn't publish a wheel, and because it has an implicit dependency on setuptools, I'm attempting to use
--use-pep517
to force pip to ensure that setuptools/wheel are present for building, but when I do, pip fails to install wheel:Expected behavior
pip
should be able to assemble a build environment, either by disabling theno-binary
option for those requirements or (preferably) by providing a bootstrap environment for these build dependencies.Note: This may be an issue that can be addressed with wheel.
The text was updated successfully, but these errors were encountered: