Develop Reference

Python's default venv environment [duplicate]

As part of the compilation step for a new python version, I fetch and run get-pip.py, to have the latest pip installed next to the python executable:
$ /opt/python/3.7.0/bin/python --version
Python 3.7.0
$ /opt/python/3.7.0/bin/pip --version
pip 18.0 from /opt/python/3.7.0/lib/python3.7/site-packages/pip (python 3.7)
I have 25 such versions under /opt/python, although I mostly use the five latest versions of each major.minor version that is not EOL. To setup an invironment I used to run virtualenv or my virtualenvutils with the -p /opt/python/X.Y.Z/bin/python option to get a virtual environment with a specific version.
With Python 3.7 this gives the imp module deprecation warning:
$ virtualenv -p /opt/python/3.7.0/bin/python /tmp/py37virtualenv
Running virtualenv with interpreter /opt/python/3.7.0/bin/python
Using base prefix '/opt/python/3.7.0'
/opt/util/virtualenvutils/lib/python3.6/site-packages/virtualenv.py:1041: DeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses
import imp
New python executable in /tmp/py37virtualenv/bin/python
Installing setuptools, pip, wheel...done.
I have little hope this will be solved in virtualenv, as this has had a PendingDeprecationWarning at least since 2014 (as can be seen from the output in this question)
While investigating replacing virtualenv with python -m venv in virtualenvutils, I first created a new venv based virtual environment by hand:
$ /opt/python/3.7.0/bin/python -m venv /tmp/py37venv
$ /tmp/py37venv/bin/pip --version
pip 10.0.1 from /tmp/py37venv/lib/python3.7/site-packages/pip (python 3.7)
That has an old pip version! If you use it, you'll get:
You are using pip version 10.0.1, however version 18.0 is available.
You should consider upgrading via the 'pip install --upgrade pip' command
In the virtual environment created with virtualenv you immediately get the latest version:
$ /tmp/py37virtualenv/bin/pip --version
pip 18.0 from /tmp/py37virtualenv/lib/python3.7/site-packages/pip (python 3.7)
I can run a post-creation step:
/tmp/py37venv/bin/pip install -U --disable-pip-version-check pip
which will take extra time. And if there was a some security update for pip, this would imply running the non-secure version to get a secure version, an ideal point of attack.
From virtualenvutils it is trivial to do the multiple steps to create a pip-less virtualenv and then add pip using get-pip.py. From the command-line this is not so simple:
$ /opt/python/3.7.0/bin/python -m venv --without-pip /tmp/py37venvnopip
$ /tmp/py37venvnopip/bin/python -c "from urllib.request import urlopen; response = urlopen('https://bootstrap.pypa.io/get-pip'); open('/tmp/tmp_get_pip.py', 'w').write(response.read())"
$ /opt/python/3.7.0/bin/python /tmp/tmp_get_pip.py
......
$ /opt/python/3.7.0/bin/pip --version
pip 18.0 from /opt/python/3.7.0/lib/python3.7/site-packages/pip (python 3.7)
What is causing /opt/python/3.7.0/bin/python -m venv to take that old pip version? Is that the version available when 3.7.0 was released?
How can I update my install under /opt/python/3.7.0 in some way so that using /opt/python/3.7.0/bin/python -m venv creates a virtualenv with the latest pip version without reverting to scripts, aliases or using multiple commands? Having the latest pip installed under /opt/python/3.7.0 obviously is not enough.
There are two bundled wheels:
/opt/python/3.7.0/lib/python3.7/ensurepip/_bundled/setuptools-39.0.1-py2.py3-none-any.whl
/opt/python/3.7.0/lib/python3.7/ensurepip/_bundled/pip-10.0.1-py2.py3-none-any.whl
I suspect I need to update those. Is there a better way than updating those by hand? Some option for /some/python -m venv would be nice.
(And running /some/python -m ensurepip --upgrade doesn't do the trick)
Running the deprecated /opt/python/3.7.0/bin/pyvenv has the same old pip version problem.

The trick is not to install the bundled version of pip (which will almost always be out of date), but to use it to install the most current version from the internet.
Standard library venv offers a --without-pip flag that can help here. After creating the virtual environment without pip, you can then you can "execute" ensurepip's wheel directly thanks to Python's zip importer. This is both faster and less hacky than installing pip and then immediately using that same pip installation to uninstall itself and upgrade.
Code speaks louder than words, so here's an example bash function for the process I've described:
# in ~/.bashrc or wherever
function ve() {
local py="python3"
if [ ! -d ./.venv ]; then
echo "creating venv..."
if ! $py -m venv .venv --prompt=$(basename $PWD) --without-pip; then
echo "ERROR: Problem creating venv" >&2
return 1
else
local whl=$($py -c "import pathlib, ensurepip; whl = list(pathlib.Path(ensurepip.__path__[0]).glob('_bundled/pip*.whl'))[0]; print(whl)")
echo "boostrapping pip using $whl"
.venv/bin/python $whl/pip install --upgrade pip setuptools wheel
source .venv/bin/activate
fi
else
source .venv/bin/activate
fi
}
If you prefer the older project virtualenv, it also offers --no-pip, --no-setuptools, and --no-wheel flags to achieve the same on Python 2.7.
Note: Python 3.9+ venv has an --upgrade-deps option to immediately upgrade the pip/setuptools versions after creating an environment, see https://bugs.python.org/issue34556 for more info about that. I don't use this option because it still goes through an unnecessary install/uninstall of the vendored versions, which is inferior to the method of creating an environment with the latest versions directly as shown above.

I use upgrade-ensurepip to update those pip and setuptools wheel files that are part of the ensurepip package. It's not as elegant as being able to upgrade ensurepip via pip, but it's still preferable to doing it manually.
https://pypi.org/project/upgrade-ensurepip/

It is an expected behavior. python -m venv calls python -m ensurepip to install pip and This answer shows that ensurepip would only install the bundled version even with --upgrade option. There isn't any official option to update the bundled pip and setuptools.
Well I have also no good idea to fix this problem as it just is the designed behavior. I would like to give two suggestions:
Use pipenv. It is really good! And it will be the next-generation official package manager in the future(Although there is a big problem related to current Pypi's structure. In short, a package manager can only decide the dependencies with downloading the whole package. This gives a huge difficulty to building dependencies graph.).
Implement your custom EnvBuilder, actually there is an official example about this. And in the example, it also use get-pip.py to install the latest pip.

Virtualenv with pyenv gives wrong python version

I have pyenv installed on an up to date debian testing distribution, and have python 2.7.1 in it.
I create a virtualenv for a project with this version, but when activated it gives me the python system version (3.7).
Here is what I did:
$ pyenv virtualenv 2.7.16 my_project-2.7
Requirement already satisfied: virtualenv in /home/user/.local/lib/python2.7/site-packages (15.1.0)
You are using pip version 18.1, however version 19.1.1 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.
Using base prefix '/usr'
New python executable in /home/user/.pyenv/versions/2.7.16/envs/my_project-2.7/bin/python
Installing setuptools, pip, wheel...
done.
Installing pip from https://bootstrap.pypa.io/get-pip.py...
Collecting pip
Using cached https://files.pythonhosted.org/packages/5c/e0/be401c003291b56efc55aeba6a80ab790d3d4cece2778288d65323009420/pip-19.1.1-py2.py3-none-any.whl
Installing collected packages: pip
Found existing installation: pip 19.1.1
Uninstalling pip-19.1.1:
Successfully uninstalled pip-19.1.1
Successfully installed pip-19.1.1
$ pyenv activate my_project-2.7
pyenv-virtualenv: prompt changing will be removed from future release. configure `export PYENV_VIRTUALENV_DISABLE_PROMPT=1' to simulate the behavior.
$ python --version
Python 3.7.3
$ pip --version
pip 19.1.1 from /home/user/.pyenv/versions/2.7.16/envs/my_project-2.7/lib/python3.7/site-packages/pip (python 3.7)
It is strange. The virtualenv is correctly set into ~/.pyenv/version/2.7.16, but I can see that pip come from /home/user/.pyenv/versions/2.7.16/envs/my_project-2.7/lib/python3.7/
I think I missed something, or I might have some mess in my python installation, but I can't find out what this python3.7 lib is doing here.
How can I have this virtualenv created for python2.7 ?
Edit
I tried to completely remove pyenv (removing the $(pyenv root) directory), then reinstall it with pyenv-installer but it did not change anything.
I created two virtualenvs for two projects I have (the above 2.7 and one in 3.5).
$ pyenv virtualenvs
2.7.16/envs/my_project-2.7 (created from /usr)
3.6.8/envs/other_project-3.6 (created from /home/user/.pyenv/versions/3.6.8)
my_project-2.7 (created from /usr)
other_project-3.6 (created from /home/user/.pyenv/versions/3.6.8)
I think the problem could be found from this created from /usr but I don't understand what it means. Why was this virtualenv not created from the pyenv python version ? Is it at all relevant ?
It seems that when I create a 3.+ virtual env, venv is used. But on 2.7, virtualenv is used and fails.

WFM as written if I install pyenv and pyenv-virtualenv from scratch according to the linked instructions.
I can see that pip come from /home/user/.pyenv/versions/2.7.16/envs/my_project-2.7/lib/python3.7/
This shows that most probably, that virtual environment already exists and has a wrong Python version.
I can only conjecture how it ended up like this. Most probably, you were messing with that virtualenv or with pyenv envvars by hand; or ran scripts/have something in your bash stratup scripts that do that. E.g. if you are using pyenv-virtualenv commands to manage your environments, you are not supposed to mix them with regular virtualenv commands.
Deleting this virtualenv with pyenv virtualenv-delete my_project-2.7 then recreating it should help.
If not, delete ~/.pyenv and everything relevant from your startup scripts, restart the shell and reinstall pyenv and pyenv-virtualenv.
For a less destructive fixing, you need to carefully inspect your shell environment (envvars, aliases, defined shell functions) and startup scripts for anything that might conflict with pyenv's work; if that doesn't help, debug pyenv machinery (export PS4='+(${BASH_SOURCE}:${LINENO}): ${FUNCNAME[0]:+${FUNCNAME[0]}(): }' helps here very much) to find out what exactly is happening.

Using pip on Windows installed with both python 2.7 and 3.5

I am using Windows 10. Currently, I have Python 2.7 installed. I would like to install Python 3.5 as well. However, if I have both 2.7 and 3.5 installed, when I run pip, how do I get the direct the package to be installed to the desired Python version?

You will have to use the absolute path of pip.
E.g: if I installed python 3 to C:\python35, I would use:
C:\> python35\Scripts\pip.exe install packagename
Or if you're on linux, use pip3 install packagename
If you don't specify a full path, it will use whichever pip is in your path.

Because usually i change my intepreter to run something(i got 2 diff projects with both 2 and 3), i use these solution:
Add path to the environment as usual (of course)
Rename ur python.exe , in my case i want to run python 3 using command python3 on my cmd. So i renamed my python.exe in python3.x directory with python3. Itll works with python 2 ofc.
Then to use pip in both python, i use this command.
python3 -m pip install 'somepackage'
and to run pip on python2
python -m pip install 'somepackage'
This is may not the best solution out there, but i like this one
** WINDOWS **
ref : https://datascience.com.co/how-to-install-python-2-7-and-3-6-in-windows-10-add-python-path-281e7eae62a

In my case, I have Python 2.7 and Python 3.4, with the Python Launcher for Windows.
This is the output when running this commands:
PS C:\> pip -V
pip 9.0.1 from c:\python27\lib\site-packages (python 2.7)
PS C:\> pip3 -V
pip 9.0.1 from C:\Python34\lib\site-packages (python 3.4)
I'll note that in my Python27\Scripts\ directory, I have pip.exe, pip2.exe and pip2.7.exe.
And in my Python34\Scripts\ directory, I have pip.exe, pip3.exe and pip3.4.exe.
So all of these .exe files help you when you have different versions of Python installed at the same time.
Of course, for this to work, you have to have the respective Scriptsdirectries in your Path system enviroment variable.

The answer from Farhan.K will work. However, I think a more convenient way would be to rename python35\Scripts\pip.exe to python35\Scripts\pip3.exe assuming python 3 is installed in C:\python35.
After renaming, you can use pip3 when installing packages to python v3 and pip when installing packages to python v2. Without the renaming, your computer will use whichever pip is in your path.

I would advise against ever calling any pip script directly (nor pip3, pip2.7.exe, anything like that).
Instead, a surefire way is to always prefer the explicit variant of calling pip's executable module for a specific Python interpreter:
path/to/pythonX.Y -m pip somecommand
path/to/venv/bin/python -m pip somecommand
C:\path\to\venv\Scripts\python.exe -m pip somecommand
There are many advantages to this, for example:
It is explicit for which Python interpreter the projects will be pip-installed (Python 2 or 3, inside the virtual environment or not, etc.)
For a virtual environment, one can pip-install (or do other things) without activating it: path/to/venv/bin/python -m pip install SomeProject
Under Windows this is the only way to safely upgrade pip itself path\to\venv\Scripts\python.exe -m pip install --upgrade pip
But yes, if all is perfectly setup, then python3 -m pip install SomeProject and pip3 install SomeProject should do the exact same thing, but there are way too many cases where there is an issue with the setup and things don't work as expected and users get confused (as shown by the many questions about this topic on this platform).
References
Brett Cannon's article "Why you should use python -m pip"
pip's documentation section on "Upgrading pip"
venv's documentation section on "Creating virtual environments": "You don’t specifically need to activate an environment [...]"

I ran across an issue with running pip with absolute path. This might be related to WinPython's installation routine and the order of installing Python 3.6 first, 2.7 second, or Python 3.6 being in the path.
No matter which pip was called, it was activating the 3.6 one:
λ C:\prog\WinPython-64bit-2.7.13.1Zero\python-2.7.13.amd64\Scripts\pip2.exe --version
pip 9.0.1 from C:\prog\WinPython-64bit-3.6.1.0Zero\python-3.6.1.amd64\lib\site-packages (python 3.6)
What finally did the trick was calling pip as a module of the respective python binary:
λ C:\prog\WinPython-64bit-2.7.13.1Zero\python-2.7.13.amd64\python.exe -m pip --version
pip 9.0.1 from C:\prog\WinPython-64bit-2.7.13.1Zero\python-2.7.13.amd64\lib\site-packages (python 2.7)
Hope that might help someone with similar issues.

I tried many things , then finally
pip3 install --upgrade pip worked for me as i was facing this issue since i had both python3 and python2.7 installed on my system.
mind the pip3 in the beginning and pip in the end.
And yes you do have to run in admin mode the command prompt and make sure if the path is set properly.

1-open command prompt and change direction using the command cd C:\Python35\Scripts
2- write the command pip3 install --upgrade pip
3- close the command prompt and reopen it again to return to the default direction and use the command pip3.exe install package_name to install any package you want

How to override the pip command to Python3.x instead of Python2.7?

I am using OSX and I have pip installed for both Python3.5 and Python2.7. I know I can run the command pip2 to use Python2 and when I use the command pip3 Python3.x will be used.
The problem is that the default of pip is set to Python2.7 and I want it to be Python3.x.
How can I change that?
edit:
No, I am not running a virtual environment yet. If it was a virtual environment I could just run Python3.x and forget all about Python2.7, unfortunately since OSX requires Python2.7 for it's use I can't do that. Hence why I'm asking this.
Thanks for the answer. I however don't want to change what running python does. Instead I would like to change the path that running pip takes. At the moment pip -V shows me pip 8.1.2 from /Library/Python/2.7/site-packages (python 2.7), but I am looking for pip 8.1.2 from /Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages (python 3.5) I am sure there has to be a way to do this. Any ideas?

Run this:
pip3 install --upgrade --force pip
or even more explicit:
python3 -m pip install --upgrade --force pip
This will install pip for Python 3 and make Python 3 version of pip default.
Validate with:
pip -V

I always just run it via Python itself, this way:
python3 -m pip install some_module
or
python2 -m pip install some_module
The -m calls the __main__.py module of a specified package. Pip supports this.

Can't you alias pip='pip3' in your ~/.bash_profile?
In Terminal, run nano ~/.bash_profile, then add a line to the end that reads alias pip='pip3'. This is safe; it won't affect system processes, only your terminal.

For your projects, you should be using a virtualenv.
You can choose which python will be that of the virtualenv at creation time, by specifying it on the command line:
virtualenv -p python3 env
# then
. env/bin/activate
python # ← will run python3
That python interpreter will be the one used when you run python or pip while the virtualenv is active.
Under the hood, activating the virtualenv will:
modify your PATH environment setting so binaries in env/bin
override those from your system.
modify your PYTHONHOME
environment setting so python modules are loaded from env/lib.
So python, pip and any other package you install with pip will be run from the virtualenv, with the python version you chose and the package versions you installed in the virtualenv.
Other than this, running python without using virtualenv will just run the default python of the system, which you cannot usually change as it would break a lot of system scripts.

It works for me:
As super-user
Uninstall pip
sudo pip uninstall pip
Install pip
sudo python3 -m pip install --upgrade --force pip
Check install path
sudo pip -V
As local-user
Uninstall pip
pip uninstall pip
Install pip
python3 -m pip install --upgrade --force pip
Check install path
pip -V

Although PEP 394 does not specifically mention pip, it does discuss a number of other Python-related commands (including python itself). The short version is that, for reasons of backwards compatibility, the unversioned commands should refer to Python 2.x for the immediate future on most reasonable systems.
Generally, these aliases are implemented as symbolic links, and you can just flip the symlink to point at the version you want (e.g. with ln -f -s $(which pip3) $(which pip) as root). But it may not be a good idea if you have any software that expects to interact with Python 2 (which may be more than you think since a lot of software interacts with Python).
The saner option is to set up a Virtualenv with Python 3. Then, within the Virtualenv, all Python-related commands will refer to 3.x instead of 2.x. This will not break the system, unlike the previous paragraph which could well break things.

Since you have specified in the comments you want syntax like pip install [package] to work, here is a solution:
Install setuptools for Python3: apt-get install python3-setuptools
Now pip for Python3 could be installed by: python3 -m easy_install pip
Now you can use pip with the specific version of Python to
install package for Python 3 by: pip-3.2 install [package]

Why not just repoint the link /bin/python to python3? It seems like the easiest solution. Especially if you want it for all users of your system.

How to force virtualenv to install latest setuptools and pip from pypi?

Is it possible to force virtualenv to use the latest setuptools and pip available from pypi? Essentially, I'm looking for the opposite of the --never-download flag.
Currently, when I make a new virtualenv, it uses the local (old) versions that come bundled with virtualenv.
$ v.mk testvenv
New python executable in testvenv/bin/python
Installing setuptools............done.
Installing pip...............done.
$ pip show setuptools
---
Name: setuptools
Version: 0.6c11
Location: /Users/cwilson/.virtualenvs/testvenv/lib/python2.7/site-packages/setuptools-0.6c11-py2.7.egg
Requires:
$ pip search setuptools
[...]
setuptools - Easily download, build, install, upgrade, and
uninstall Python packages
INSTALLED: 0.6c11
LATEST: 0.7.2
[...]

It's not supported for security reasons.
Using virtualenv.py as an isolated script (i.e. without an associated
virtualenv_support directory) is no longer supported for security
reasons and will fail with an error. Along with this, --never-download
is now always pinned to True, and is only being maintained in the
short term for backward compatibility (Pull #412).
I can't use the --extra-search-dir option either because it's currently broken https://github.com/pypa/virtualenv/issues/327
Looks like the only option is to simply wait for the virtualenv maintainers to update the bundled packages?

You can upgrade pip after installing your virtualenv by using pip install -U pip.
I'm sure you could write a bootstrap-script to automate this step.

I needed the latest setuptools library, and the --extra-search-dir flag wasn't working for me (even though it's been fixed apparently).
However, making a virtualenv without setuptools and then installing directly from PyPi worked great.
E.g. to set up a virtualenv called test:
virtualenv --no-setuptools test
source test/bin/activate
wget https://bootstrap.pypa.io/ez_setup.py -O - | python
easy_install pip
Testing with
python -c 'import setuptools; print setuptools.__version__'
shows the right version.

I ran into the same problem, and I fixed it by upgrading setuptools.
If env is your virtual env, run the following:
$ env/bin/pip install --upgrade setuptools

Building on ematsen's excellent answer I made a bash script that works with virtualenvwrapper
#!/bin/bash
source `which virtualenvwrapper.sh`
mkvirtualenv --no-setuptools $1
wget https://bootstrap.pypa.io/ez_setup.py -O - | python
rm setuptools-*.zip
easy_install pip
# for python version < 2.7.9
# https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
pip install urllib3[secure]