Let's look at use cases.

1) User wants to pip install something into their ~/.local directory.
Having python3-* packages installed does not give them pip3.  They have
to apt-get install python3-pip.  If they try to `pip3 install foo` it
will try to install it into the system dist-packages and this will fail
with a permission denied.  They must `pip3 install --user foo` and it
will end up in their ~/.local/lib/pythonX.Y/site-packages directory, and
it will be importable by the system Python.  All of this works right out
of the box today:

% pip3 install --user nose2
[...]
% python3.4 -c "import nose2; print(nose2)"
<module 'nose2' from 
'/home/barry/.local/lib/python3.4/site-packages/nose2/__init__.py'>

2) User wants to pip install something into the system package path.
Again they must install python3-pip, and this time they must use `sudo
pip3 install foo`.  foo gets installed into /usr/local/lib/python3.4
/dist-packages.   All of this works right out of the box today:

% sudo pip3 install nose2
[...]
% python3.4 -c "import nose2; print(nose2)"
<module 'nose2' from '/usr/local/lib/python3.4/dist-packages/nose2/__init__.py'>

3) Use creates a virtualenv and wants to install foo into the
virtualenv.  Regardless of whether --system-site-packages is used or
not, and regardless of whether pyvenv-3.4 or virtualenv is used, the
virtualenv should already contain `/my/venv/bin/pip` and the user should
be able to enter the venv and run `pip install foo`.  This should
install foo into /my/venv/lib/pythonX.Y/site-packages and have it be
importable.

This latter is the use case that's currently broken with pyvenv-3.4 due
to the disabling of ensurepip, so this is the use case we need to fix.
System pip package shouldn't enter into the picture.  The question we
have to answer, IMHO, is whether we want ensurepip to use the
recursively bundled pip (and its dependencies) or to rewheel system pip
and dependencies (in which case we'd need to handle the circular apt
dependencies from python3.4->python3-pip).

I think the determining factor should be Debian policy w.r.t. build-
from-source.  Wheels are just zips so unzipping the two bundled wheels
results in all the recursive source files contained within the wheels.
But how are the wheels built to be included in the tarball?  That recipe
must be embodied in the Debian package so that the bundled wheels (with
their own vendored libraries) can be completely reproduced from upstream
source.

If it's not possible to do that reproducibly, then we need an approach
like rewheel.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1290847

Title:
  pyvenv fails due to mising ensurepip module

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python3-defaults/+bug/1290847/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to