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?
One big issue with not having pip in virtual environment's bin/ is that
users will probably use 'pip install foo' inside the activated virtual
environment and be surprised by not being able to install anything.
Many of them might not know the 'python -m pip install foo' variant.
That means you have to pass "--ignore-installed" to get pip
to
actually install into the virtual environment properly:
(venv2) $ which pip
/usr/bin/pip
(venv2) $ python -m pip install --ignore-installed pip
Collecting pip
Using cached pip-9.0.1-py2.py3-none-any.whl
Installing collected packages: pip
(venv2) $ which pip
/tmp/venv2/bin/pip
Well, it is not always necessary :). If there would be a newer pip
available on PyPI than the installed system site packages version, one
could also get away with:
(myvenv3) $ python3 -m pip install -U pip
Collecting pip
Using cached pip-9.0.1-py2.py3-none-any.whl
Installing collected packages: pip
Found existing installation: pip 8.1.2
Not uninstalling pip at /usr/lib/python3.5/site-packages, outside
environment /home/vagrant/myvenv3
Successfully installed pip-9.0.1
(myvenv3) $ ls myvenv3/bin
activate activate.csh activate.fish pip pip3 pip3.5 python pytho
n3
I think that makes sense at least as a BZ against the Fedora Python
3
package (to pass --ignore-installed when installing components into
the venv), and it may even make sense to file it as a bug against
CPython upstream as well, since it will happen any time you have the
three way combination of:
- system wide installation of pip
- using native stdlib venv creation
- the created venv is configured to have access to the system site
packages
Agreed, I'll file appropriate bug reports, but first I would like to
make the issues clearer in my head :).
As I see it, there are two issues when one has the aforementioned three
way combination:
1) Users will probably use 'pip install foo' inside the activated
virtual environment and be surprised by not being able to install
anything.
Many of them might not know the 'python -m pip install foo' variant.
2) Users that know the 'python -m pip install' variant may want to
install a package inside the virtual environment that is already
available in system site-packages . The installation won't work unless
they pass the '--ignore-installed' option or they install a newer
version of the same package with '--upgrade' option.
Does this make sense?
Thanks,
Tadej
[
1] https://docs.python.org/3/library/venv.html