-
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
pip isolated build breaks when a pth file imports setuptools and setup_requires is defined #7778
Comments
Note, even putting the import into a try-catch has no effect, e.g switch the above pth generation with: echo 'import magic' 1>venv/lib/python3.8/site-packages/magic.pth
printf 'try:\n import setuptools\nexcept:\n pass' 1>venv/lib/python3.8/site-packages/magic.py Note an empty |
So the issue is here, https://github.com/pypa/pip/blob/master/src/pip/_internal/build_env.py#L87-L108. Seems pip part of building the environment injects some additional pth files via the
to that generated script fixes the issue. Not sure what's a good solution here though, as obviously pip might not be able to cater all build envs that could build-cache before the |
- check build requirements for conflicts - better isolation (ignore system site packages) - support 2 prefixes: a "normal" one, and an "overlay" one (with higher priority over "normal")
…nt (#1657) * Ensure distutils configuration values do not escape virtual environment Distutils has some configuration files where the user may alter paths to point outside of the virtual environment. Defend against this by installing a pth file that resets this to their expected path. Signed-off-by: Bernat Gabor <[email protected]> * fix CI failure due to #pypa/pip/issues/7778 Signed-off-by: Bernat Gabor <[email protected]>
I have to say that my immediate reaction is "don't do that". I'm not a huge fan of What is the actual use case for this? |
I should also say that not reacting to changes in the working set sounds like a bug (or deliberate limitation?) in setuptools. |
Needed for pypa/virtualenv#1635 That being said pth files are officially documentend interface so I don't think we can say don't do that. |
Well depends where you stand. Should virtual environments support setuptools, or setuptools support virtual environments? Given the issue arrives only in virtual environments, I'm tempted to put here the responsibility on the virtual environment. |
My point was that if, as you say, this is legitimate usage, then why is it OK for setuptools not to support it? But never mind, debating who's at fault isn't productive here.
So if I'm understanding correctly, the use case is a project that wants to use How necessary is As I've said elsewhere, I'm not against a PR that fixes this. I'm just saying that I don't think there's any particular reason to consider that the assumptions pip's current code is making are particularly unreasonable. But we're going to get nowhere debating who or what is doing something "wrong" here. I'm happy to drop this discussion so that the conversation can focus on developing a fix (wherever that fix ends up going). |
Yes. All these three need to come into play for the issue to arise. There's an outstanding issue for
I am not sure what setuptools should/can do here to assist with the issue. At best maybe provide an API to disable those configurations values, so we don't have to monkeypatch. But that would not bring us any more ahead in the pip build side.
For older target machines (think Ubuntu LTS, Debian LTS) that don't have the newer pip versions, it helps to fallback to
Unreasonable, definitely not. A bit brittle when |
According to pypa/setuptools#1742 (Edit: For clarification, I don’t object to fixing the issue if it’s reasonable.) OT: Old Debian and Ubuntu releases seem to pop up often recently ( |
My impression was that you'd said setuptools queries the working set at import time and caches that value. I was assuming that "calculate the working set as needed" would fix the issue. Apologies if I misunderstood.
That sounds reasonable to me - thanks. |
FYI, I've released virtualenv 20.0.6, that generates a pth file for every virtual environment (to patch distutils), so this issue might get more important; if nothing else we'll see how common the use case is. (and based on that we can have a good guess what to do next) - would it be possible to do a pip patch release in the next week, would this PR manifest? |
This is a big problem for us. |
This is also affecting us greatly. |
For now side-step the issue in virtualenv, by reverting our fix - https://virtualenv.pypa.io/en/latest/changelog.html#v20-0-7-2020-02-26 |
Write version number to static file on install, to avoid overhead of looking it up every time datacube is imported. Using pyproject.toml avoids issue pypa/pip#7778
Write version number to static file on install, to avoid overhead of looking it up every time datacube is imported. Using pyproject.toml avoids issue pypa/pip#7778
The following script reproduces the problem:
Ran into this while trying to fix pypa/virtualenv#1657
The text was updated successfully, but these errors were encountered: