BackendUnavailable traceback with 19.0 #6164
Comments
|
Can you please:
I suspect the issue is that the failing project is not specifying the backend in its |
|
Here's my requirements.txt. I will work on a minimal reproducer, but I've not been having any luck on reproducing this outside of AWS Elastic Beanstalk's deployment process. I'll keep trying. |
|
Thanks - but yeah, we'll need something smaller. Also, if it's not reproducible outside AWS, it's going to be difficult for us to diagnose or offer any suggestions :-( |
|
I reduced the requirements.txt down to the following: Both are required, though. If you remove either, the problem goes away. I can reproduce it reliably on AWS Linux now but not on Ubuntu. |
|
OK, neither of those projects use |
|
setuptools is at 28.8.0. Here is the debug output. |
|
OK, from the log pip is installing setuptools 40.6.3. So that's OK. But then the backend is failing with In def _build_backend():
"""Find and load the build backend"""
ep = os.environ['PEP517_BUILD_BACKEND']
mod_path, _, obj_path = ep.partition(':')
try:
obj = import_module(mod_path)
except ImportError:
raise BackendUnavailable
if obj_path:
for path_part in obj_path.split('.'):
obj = getattr(obj, path_part)
return objIf you can delete the lines except ImportError:
raise BackendUnavailableyour test should fail with an Let me know the output and we'll see what that tells us. |
|
|
OK, so it looks like somehow either pip didn't install setuptools 40.6.3 in the build environment, in spite of what the log seems to say, or pip is somehow seeing the ancient setuptools 28.8.0 from the system. But I don't know why either of those would be the case. Do you have command line access to the system? If so, I'd suggest doing something like inserting a call to os.system("bash") at the start of |
|
That doesn't seem to work. bash seems to exit right away when run from within pip (is perhaps pip closing stdin or something?). It does work when I run it in a standalone script though. |
|
In pypa/setuptools#1644, the setuptools project itself has encountered this issue, although it seems only to happen on Python 2.7. |
|
@swt2c Did you do an |
|
Yes, I did but it didn't work. See my previous comment. |
|
Hmm... Does |
|
@pradyunsg At this point in the code, I think pip has closed stdin (to handle the case of |
|
Oh, this is in a subprocess! Oh I didn't realize for some reason. Well, I don't remember how to do that off the back of my head either - I'd suggest just commenting out the relevant line at https://github.com/pypa/pip/blob/master/src/pip/_internal/utils/misc.py#L717 Line 177 or similar that's closing stdin. |
|
@swt2c Could you comment out the line containing |
pradyunsg
added
S: awaiting response
|
Okay, so commenting out the closing of stdin didn't work - it just made the script sort of hang there. I ended up just inserting a massive Anyway, I can inspect the environment now but I'm not really sure what I'm looking for. In the /tmp/pip-build-env-sig37k9z directory, it appears that setuptools 40.7.1 is installed. I don't really know what else to look at, so I'm attaching a tarball of the environment, in case anyone else wants to look at it. |
pradyunsg
removed
the
S: awaiting response
|
@pfmoore Do you think you'd have the time to make a fix for this anytime soon? Do you think just putting the last line of the traceback in the output would be helpful with this? I'm not interested in blocking 19.0.2 on this but I'd like to know what your thoughts are. |
|
We don't have any idea what the problem is yet (I suspect it may be AWS-specific). A PR to give better diagnostics for a I've had little or no time in front of a PC with an actual development environment on it, basically since the new year and likely for a while yet (between RL distractions and PC rebuilds) so please don't hold anything up on the assumption that I'll be able to provide a fix - sorry. |
|
No worries. :) I'll drop this from 19.0 then. |
To add to the weirdness, I have the same issue on Azure with Pypy3 (installed on Debian 9 from Debian 10's repo), when intalling |
|
I just hit this in a virtualenv that was set up with edit: |
|
Newer versions of pip (>=19.0) don't work with older versions of setuptools (<40) due to an attribute error. If `include_system_packages` is `false` (now the default), this is not an issue because of the newer setuptools that gets installed into the venv. However, when it's `true`, which is required for some charms, the install fails because pip somehow prefers the older system-installed setuptools over the newer one in the venv. Pinning pip avoids the problem until we can find a better solution. See: * https://discourse.jujucharms.com/t/wheel-building-fails-during-charm-deployment/1947 * pypa/pip#6164
Newer versions of pip (>=19.0) don't work with older versions of setuptools (<40) due to an attribute error. If `include_system_packages` is `false` (now the default), this is not an issue because of the newer setuptools that gets installed into the venv. However, when it's `true`, which is required for some charms, the install fails because pip somehow prefers the older system-installed setuptools over the newer one in the venv. Pinning pip avoids the problem until we can find a better solution. See: * https://discourse.jujucharms.com/t/wheel-building-fails-during-charm-deployment/1947 * pypa/pip#6164
|
Me and someone else have this same issue when installing pyinstaller. With the This is on macOS 10.14. I can |
|
I did a little bit of investigating.
This printed It bloody works! What? Ok my next guess is that some environment variable is being set in my bash shell, but not in this subprocess, and that means Python can find some modules for me but not for the subprocess (say NO to environment variables! (cough also python cough)). It had added the temp directory |
|
Ok I can no longer reproduce this. It now installs fine and I think the only thing I did was I have seen this before where running So my recommendation is to always run |
|
I am still getting this issue when trying to upgrade pyinstaller(3.3.1 -> 3.5) using pip(19.3.1) and setuptools(42.0.2). I get following error: I'm getting it on a normal Windows 10 install not any cloud platform. Is there a fix for this? |
|
I just tried the following from a new EC2 instance ( Can anyone provide clear instructions to reproduce this issue, from beginning to end, ideally from a clean cloud instance, Docker image, or Windows VM (from here)? Here are the kinds of details we need:
|
chrahunt
added
S: awaiting response
|
I'm not sure how this could happen, because I didn't do any manual editing of my virtual env. But after I deleted it and started from scratch everything installed fine. So for me the issue is gone, although I'm not sure why it happened in the first place. |
|
I was trying out poetry, and this was solved for me when i deleted the |
|
This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further. |
lock
bot
added
the
auto-locked
pradyunsg
removed
the
S: awaiting response
Environment
Description
pip tracebacks with a BackendUnavailable Exception when running 'pip install -r requirements.txt'. Reverting to 18.1 avoids this problem.
Expected behavior
pip installs successfully
How to Reproduce
Run pip install -r requirements.txt.
Output
The text was updated successfully, but these errors were encountered: