GNU bug report logs - #39930
python-virtualenv produces a broken pip when network is available

Previous Next

Package: guix;

Reported by: Jakub Kądziołka <kuba <at> kadziolka.net>

Date: Thu, 5 Mar 2020 17:06:01 UTC

Severity: normal

To reply to this bug, email your comments to 39930 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-guix <at> gnu.org:
bug#39930; Package guix. (Thu, 05 Mar 2020 17:06:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jakub Kądziołka <kuba <at> kadziolka.net>:
New bug report received and forwarded. Copy sent to bug-guix <at> gnu.org. (Thu, 05 Mar 2020 17:06:01 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jakub Kądziołka <kuba <at> kadziolka.net>
To: bug-guix <at> gnu.org
Subject: python-virtualenv produces a broken pip when network is available
Date: Thu, 5 Mar 2020 18:06:22 +0100
[Message part 1 (text/plain, inline)]
I am encountering a weird error:

| ~/tmp$ guix environment --pure --ad-hoc python python-virtualenv coreutils
| ~/tmp% pip3 --version
| pip 19.0.3 from /gnu/store/az4z48nrlyhrpkj2njs6xz3p0mj71wi7-profile/lib/python3.7/site-packages/pip (python 3.7)
| ~/tmp% virtualenv venv
| Using base prefix '/gnu/store/608bvypsh90c58apvd2cgg3m9l2pwjqn-python-3.7.4'
| New python executable in /home/kuba/tmp/venv/bin/python
| Installing setuptools, pip, wheel...
| done.
| ~/tmp% . venv/bin/activate
| (venv) ~/tmp% pip3 --version # or any other command
| Traceback (most recent call last):
|   File "/home/kuba/tmp/venv/bin/pip3", line 7, in <module>
|     from pip._internal.cli.main import main
| ModuleNotFoundError: No module named 'pip._internal.cli.main'

Note that unsetting PYTHONPATH helps:

| (venv) ~/tmp% PYTHONPATH= pip3 --version
| pip 20.0.2 from /home/kuba/tmp/venv/lib/python3.7/site-packages/pip (python 3.7)

Similarily, omitting the python package from the environment also helps:

| ~/tmp$ guix environment --pure --ad-hoc python-virtualenv coreutils
| ~/tmp% virtualenv venv
| Using base prefix '/gnu/store/608bvypsh90c58apvd2cgg3m9l2pwjqn-python-3.7.4'
| New python executable in /home/kuba/tmp/venv/bin/python
| Installing setuptools, pip, wheel...
| done.
| ~/tmp% . venv/bin/activate
| (venv) ~/tmp% pip3 --version
| pip 20.0.2 from /home/kuba/tmp/venv/lib/python3.7/site-packages/pip (python 3.7)

Interestingly, even with PYTHONPATH set, everything works in a container
started without network access:

| ~/tmp$ guix environment --container --ad-hoc python python-virtualenv coreutils
| kuba <at> gravity ~/tmp [env]$ virtualenv venv
| Using base prefix '/gnu/store/608bvypsh90c58apvd2cgg3m9l2pwjqn-python-3.7.4'
| New python executable in /home/kuba/tmp/venv/bin/python
| Installing setuptools, pip, wheel...
| done.
| kuba <at> gravity ~/tmp [env]$ . venv/bin/activate
| (venv) kuba <at> gravity ~/tmp [env]$ pip3 --version
| pip 19.0.3 from /gnu/store/az4z48nrlyhrpkj2njs6xz3p0mj71wi7-profile/lib/python3.7/site-packages/pip (python 3.7)

My guess as to what's happening: virtualenv tries to use a newer pip
than is provided by Guix. It then generates an entrypoint appropriate
for the pip version it chose and installed into the venv. Unfortunately,
the $PYTHONPATH set by Guix overrides virtualenv's mechanism for
directing Python to venv/lib/python3.7/site-packages. This makes an
entrypoint designed for pip 20.0.2 try to load pip 19.0.3. pip's main
function was relocated between releases, making this problematic.

I am not sure which part of that is wrong here, nor how to go about
fixing it. The problem would disappear temporarily when we merged
core-updates into master, but keeping up with Python's release schedule
doesn't sound feasible.

Note that while virtualenv doesn't change PYTHONPATH, it does unset
PYTHONHOME - maybe that's a more appropriate environment variable to use
for pointing Python to the primary modules directory?

While debugging this, I noticed that the virtualenv we ship is outdated.
I prepared a patchstack, which I will send later today, to update the
version to latest virtualenv. The behavior didn't change, apart from
slightly different output formatting of virtualenv.

Regards,
Jakub Kądziołka
[signature.asc (application/pgp-signature, inline)]

This bug report was last modified 4 years and 24 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.