I face the same issue, running OSX 10.10.2
and python 3.4.2
. Most recently I created a virtual environment in a debian wheezy
machine with python 3.4.3
and also ended up with an older version of pip
than available. had to upgrade pip
.
I've been upgrading pip
within the virtual environment to 6.1.1
from 6.0.8
manually, because I'm o.c.d about software library versions that way - and yes, I am upgrading my python 3
version to 3.4.3
right now. Anyway, my system's python3-pip
is the latest version 6.1.1
, so I've also wondered why pyvenv
creates a new virtual environment and loads it with old pip
.
I haven't noticed anything bad happen in any of the virtual environments due to upgrading pip
, (but on the flip side, I haven't noticed anything good either) Apparently the new pip is faster -- didn't notice, and outputs less junk on successful installs because user's don't care -- also didn't notice, probably because i'm one of those that don't care, and also comes with a state-of-the art coffee machine capable of latte art to boot!!! -- still waiting on sudo pip install latte
to finish :(
So, to answer your question, it is definitely possible, and probably advisable to upgrade, because apparently the new pip
fixes some bugs and goes faster, but I guess the speed up isn't that major, and the bug fixes don't affect all that many people (I've never faced a bug with my usage of the old pip
).
You can link to system site-packages using the flag --system-site-packages when you create a new virtual environment, like this
pyvenv myenv --system-site-packages
This will link to your system wide version of pip, and would remove the annoyance that is manually upgrading pip on every virtual environment, but if you do this, then is your virtual environment all that virtual?
update: following my rant above, I went into the venv
package's source to dig. pip
is set up by a method called _setup_pip
in the file __init__.py
, line 248
def _setup_pip(self, context):
"""Installs or upgrades pip in a virtual environment"""
# We run ensurepip in isolated mode to avoid side effects from
# environment vars, the current directory and anything else
# intended for the global Python environment
cmd = [context.env_exe, '-Im', 'ensurepip', '--upgrade',
'--default-pip']
subprocess.check_output(cmd, stderr=subprocess.STDOUT)
So, venv seems to be calling ensurepip
from the shell using the subprocess
module.
One more minute of google-fu gave me this from the documentation for ensurepip.
ensurepip.version()
Returns a string specifying the bundled version of pip that will be installed when bootstrapping an environment.
So, from the command line, the following code:
$ python3 -c 'import ensurepip; print(ensurepip.version())'
6.0.8
displays my current pip
that will be bootstrapped with ensurepip
.
I guess we're stuck with the old version of pip
for every new install until ensurepip
gets upgraded, as I can't find a way to upgrade the version of pip that comes with ensurepip