python-virtualenv produces a broken pip when network is available

  • Open
  • quality assurance status badge
Details
One participant
  • Jakub K?dzio?ka
Owner
unassigned
Submitted by
Jakub K?dzio?ka
Severity
normal
J
J
Jakub K?dzio?ka wrote on 5 Mar 2020 18:06
(address . bug-guix@gnu.org)
20200305170622.2rhgs2g7oq4dh7gu@gravity
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@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@gravity ~/tmp [env]$ . venv/bin/activate
| (venv) kuba@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
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE5Xa/ss9usT31cTO54xWnWEYTFWQFAl5hMYkACgkQ4xWnWEYT
FWTbYw//dJa3hHIVWM6OSmJ60xV4KzvvvaYyaQ5sFTCNzp+ivHJGWL/ofFz40W4q
pp6gqMdYhAhPYtfrSeYuH7zSLqsSjfCzjHgYcJPbbQ2C33scs1VAIzvHVo071tf0
yJu3b2miiNK7zf4SUqp1pcUS1eZ3jg4LobVnG7YGz1tDC2iBbC9ZNZ0rdwBwrdeD
IfUttu87JIaCh5/a2KmXSecAejL5ml2sctsa7PhHENebVAlK1Ofi7NUlXslXt3uU
wN0cLiI9XjssuEgSdRqE7d6BeKC/qaIUEbReoFK+rAQjUayjXHEo5p07CGPckI6A
5+o4CG9pOtPZNvo/fJNqdVH4UFt53iu5szEh90W4JJ40OY/Ta6tT6OP610e6Hrbk
qEYZLC8uAMThsAFNKsD2ifxD+8Hmi566R1c73Hf++a0bJhEfCGVagjv0l4Tz08mV
216io3QIi3Vp0vv1qhTzoD99o4vOibOcQSba0W5vVjAs+roZWWczDVfLZS8fZ1lF
hRJTK8Y74L32ipn4EXajjcO4r9l4xEMG5MX7jfDm/5qTJWPeRnzmNvFbNgEvbEMG
3MNgzm3ma3qpYZNWvOdhiaJXo9id1P97LQDfILxI9qauyiwWV2dC4fd2uQwpGYLt
dsybfyARP+50Hjd+j1mA/yh3xcLY+3v/YXPc3yGJy8O92CW0pRM=
=Fxid
-----END PGP SIGNATURE-----


?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 39930@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 39930
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch