-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Tests failing to run with BackendUnavailable since pip 19 #1644
Comments
In order to unblock this project, I was going to configure tox to downgrade pip after creating the environment, but tox only allows one install command, and this project has already used up that configuration option to work around another issue, and it's currently not possible to specify a pip version. |
After getting a test failure from tox, I'm able to replicate the failure outside of tox by invoking the same command tox does (or similar):
The problem, of course, is that the virtualenv doesn't have setuptools installed. Setuptools historically has relied on itself to build/install itself... but pep517 is breaking from the convention/expectation that |
I'm wrong about that. The virtualenv does have setuptools installed... it just doesn't show up with |
If I update |
This is particularly difficult to debug because of the subprocess invocation. If I put a breakpoint in the _in_process script to troubleshoot, it exits immediately because there's no pipes for stdin/stdout. |
With lots of edits in the pip codebase, I managed to get a PDB prompt inside the _in_process, and here's what I see:
Why is setuptools not available? I suspect it has something to do with the 'overlay' and the fact that the |
So it seems something is creating a clean environment of dependencies in which the build can happen, containing only the dependencies declared in build-system.requires. That makes sense. As I was tracing the code, I didn't see where that happens. |
I've used pdb-clone for debugging such cases. The build environment code is in So setuptools is a particular case, since it provides its own backend, which mean that for supporting such a use-case, the package source directory must be added to sys path, and this must be done in pip. |
I can only reproduce the issue with Python 3 when tox-venv is not installed, which is also weird. |
That's probably a pip bug in the build isolation code on a venv. |
No, it's because the versions of pip being used are different... |
Following the acceptance of #1634, setuptools' own test suite now fails. |
As you have mentioned
To find why
So step 2 is making |
Presumably even though @daa's solution works, it means that we can't actually bootstrap our PEP 517, right? We will always be relying on the previously built versions of setuptools. That will probably work for now, but this seems like it must be a bigger issue, and I think it's one we can't fix in this project, right? The issue is that we supply our own PEP 517 backend, and there's no way to declare that you depend on a PEP 517 backend that exists only in your local directory. I see two ways forward with this:
Of course with option 2 the PEP 517 bootstrapper still needs some way to build itself, and all PEP 517 build systems have this problem, so if I understand the problem correctly, the most robust solution is to pursue option 1. Is there already a ticket tracking this in |
I think the discussionin Discourse is still going somewhere, but the direction it's now going is the direction you describe here: projects that need bootstrapping should add themselves to their own |
Thinking about this, even if That basically means that we cannot have any dependencies in
I don't think number 3 is going to happen, so we're really choosing between options 1 and 2. I'm in favor of option 1, but we may want to give |
Reading pypa/pip#6222 (and based on the other threads), I think the |
Make it possible to use a more recent version of pip for tests.
Make it possible to use a more recent version of pip for tests.
Make it possible to use a more recent version of pip for tests.
Make it possible to use a more recent version of pip for tests.
Work around buggy pip detection code for "pip.exe install/update ... pip ...". commit 0d831c9 Author: Benoit Pierre <benoit.pierre@gmail.com> Date: Sat Aug 10 03:57:58 2019 +0200 improve
Work around buggy pip detection code for "pip.exe install/update pip ...".
So after the absurd amount of discussion on this, the final decision (around 9 months ago) was to modify PEP 517 to add This makes it very difficult to install our own library from [build-system]
requires = ["wheel", "setuptools>=40.0"]
build-backend = "setuptools.build_meta" We can continue to exclude |
|
After some consideration, I do think this project needs something like a bootstrapper backend, mainly to address the situation of a clean source checkout. In that situation, there is no metadata present. Setuptools currently works around that situation by requiring a separate copy of setuptools to build, which is okay, but also clumsy, because then when the sdist is built, it also declares a requirement on setuptools, even when it's not needed. |
In the above referenced pull request, I figured out that Setuptools can supply its bootstrapping metadata in a separate metadata file. There's still no way to ever make Setuptools build properly on pip 19, so it will just have to break. |
It seems that since the release of pip 19, Setuptools' own tests fail to run thus:
I suspect this is related to #1642 if not just another manifestation of the same issue.
The text was updated successfully, but these errors were encountered: