Comment 8 for bug 1308714

After talking with Matthias, I think I understand the gist of this bug.

Let's say I apt-get install python3.4 (well, a modified package that re-enables the ensurepip module). Now I use pyvenv-3.4 to create a virtual environment. With ensurepip enabled, <venv>/bin will contain pip, pip3, and pip3.4 executables. If you enter the venv (by sourcing bin/activate), those will do the right thing by installing into the venv.

However, let's say you move those aside and apt-get install python3-pip. Now enter the venv and run pip3 install enum34. That package will get installed into /usr/lib/python3.4/site-packages! Not dist-packages, and not /usr/local.

That seems bad, but I'm not sure how bad it will be in practice. If we re-enable ensurepip as in LP: #1290847 then first off, anybody entering the venv will use the <venv>/bin/pip script instead and that will work as expected. You'd have to actively manipulate your venv in a way that I don't think makes much sense, or if you do it, you know what your doing (or think you do :). If you don't run system pip3 as root, you just get the expected permission denied.

There's still the possibility that you enter the venv, delete <venv>/bin/pip*, apt-get install python3-pip, and sudo pip3 install something. Yes, that will lead to broken stuff and you pretty much had to willfully want to break your system, but if that's really a problem, then python3-pip could be changed to refuse to run if sys.prefix != sys.base_prefix (i.e. you are in a virtual environment). That would force you to use the ensurepip installed pip* executables. But of course then we'd have to resolve the problems with ensurepip.