On 8 February 2017 at 13:44, Tadej Janež <tadej.j(a)nez.si> wrote:
Nick,
thanks for your thorough answer.
On Mon, 2017-02-06 at 20:07 +0100, Nick Coghlan wrote:
>
> It's not specific to Fedora's Python 3 packaging as such, but it *is*
> specific to:
>
> - using --system-site-packages
> - having pip install in the system site packages
Yes, understood.
> However, the way Fedora handles the native venv support in Python 3
> means that this case will *always* apply when creating Python 3
> virtual environments that can see the virtual environments - the pip
> that gets installed into the virtual environment comes from
> python-pip, rather than being a bundled copy in the Python RPM.
I'm still a bit puzzled by this part.
If I understand stdlib's venv documentation correctly [1], when one
creates a virtual environment, it will use ensurepip to bootstrap pip
into the virtual environment.
However, if pip is installed in system site packages, then ensurepip
will skip the bootstrapping process, leaving the created virtual
environment without its bundled copy of pip:
$ python3 -m venv --system-site-packages myvenv3
$ source myvenv3/bin/activate
(myvenv3) $ python3 -m ensurepip
Ignoring indexes:
https://pypi.python.org/simple
Requirement already satisfied (use --upgrade to upgrade): setuptools in
/usr/lib/python3.5/site-packages
Requirement already satisfied (use --upgrade to upgrade): pip in
/usr/lib/python3.5/site-packages
(myvenv3) [vagrant@tadej-zbook ~]$ ls myvenv3/bin
activate activate.csh activate.fish python python3
Do you think this is OK or should stdlib's venv module (or ensurepip)
be changed to always create a bundled copy of pip in the virtual
environment?
What's supposed to happen is that ensurepip installs a fresh copy into
the virtual environment.
It *doesn't* happen under Python 3 on Fedora when system site-packages
is visible, because if python3 is installed, then python3-pip will
*also* be installed, and you get the behaviour you're seeing.
So this should be filed as a bug against the Fedora python package for
doing the wrong thing by default.
However, it isn't clear that this qualifies as an upstream bug, as
ensurepip in general is *supposed* to be a no-op when pip is already
installed.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia