How to Get "Python -M Venv" to Directly Install Latest Pip Version

Pip version in virtualenv

You're having a problem because you're downgrading pip, but likely not changing virtualenv's behavior of installing the default pip. How would you go about debugging this?

Find which virtualenv script is being called:

[~] type -a virtualenv                                                                                                                           
virtualenv is an alias for virtualenv --no-site-packages
virtualenv is /usr/local/bin/virtualenv

Get some information from virtualenv:

[~] head -n5 /usr/local/bin/virtualenv                                                                                                          
#!/usr/local/opt/python/bin/python2.7
# EASY-INSTALL-ENTRY-SCRIPT: 'virtualenv==1.11.5','console_scripts','virtualenv'
__requires__ = 'virtualenv==1.11.5'
import sys
from pkg_resources import load_entry_point

Now we know that virtualenv is using the Python 2.7 install located at /usr/local/opt/python/bin.

While you can follow the import path around, it's easy enough to just look in the directory we found in #2 to see which pip will get called:

[~] ls /usr/local/opt/python/bin | grep pip                                                                                                          
pip
pip2
pip2.7

and ask pip to give you its version:

    [~] /usr/local/opt/python/bin/pip -V                                                                                                        
    pip 1.5.6 from /usr/local/Cellar/python/2.7.8/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-        packages/pip-1.5.6-py2.7.egg (python 2.7)

That's why!

While I'd strongly advise fixing your SSL issue instead of downgrading pip, you have some options:

A. Downgrade the version of pip "globally" in the locations found in step 3. If you look in /usr/local/bin/pip, you'll see the following:

    #!/usr/local/opt/python/bin/python2.7
    # EASY-INSTALL-ENTRY-SCRIPT: 'pip==1.5.6','console_scripts','pip'
    __requires__ = 'pip==1.5.6'
    import sys
    from pkg_resources import load_entry_point

    if __name__ == '__main__':
        sys.exit(
            load_entry_point('pip==1.5.6', 'console_scripts', 'pip')()
        )

If you have an older version of pip in your Python path (e.g.), you should be able to substitute the version on the __requires__ and load_entry_point(... lines.

B. Tell virtualenv not to install pip by by specifying the --no-pip flag when creating a virtualenv. You will then be responsible for putting your desired pip files into the virtual environments bin and lib folders.

C. Downgrade pip everywhere. When you installed the older version of pip, it either ended up in the wrong directory or was not the first pip found by Python when going through the virtualenv setup. Be careful to call the same Python interpreter that virtualenv is calling.

(also note that you could "trick" the virtual environment by editing the activate script, but you'd be a braver person than I.)

create virtual environment using pipenv

Basically, you can't, because it doesn't depend on pip (or pipenv or poetry) where the packages should be installed. Python will install packages wherever it's configured to do based on the values of sys.prefix or sys.prefix_exec, as explained here.

If you want to manage two different versions of a dependency, the one thing I can think of is having two separate virtual environments, each with its own dependencies. Then, you can switch between environments as you please. But you can't have two versions of the same package installed (unless you modify its source and install it locally as well) in the same environment, and definitely changing between pip or any dependency installation tool won't help you.

Here's a nice article that explains what happens when you activate a virtual environment and why it does not depend on pip where they are installed

Reinstall packages automatically into virtual environment after Python major version upgrade

In your new 3.7 venv you should have pkg_resources available - setuptools is automatically installed when created. If not, just pip install setuptools.

setuptools library code is actually what pip is vendoring to make pip freeze work. But you can just freeze it manually.

# in 3.7 runtime...
import pkg_resources
old_site_dir = ".venv/lib/python3.6/site-packages/"
working_set = pkg_resources.WorkingSet([old_site_dir])
for dist in working_set:
    print(dist.as_requirement())

You can throw that output in a requirements.txt file and likely have a working reconstructed site, no python3.6 runtime required.

Note that this method may not be 100% foolproof, because it is possible for projects to declare separate dependency trees for python3.6 and python3.7 by using environment markers in their distribution metadata (see PEP 508). It is also possible that items installed in your 3.6 site do not support 3.7 at all. However it is pretty uncommon to see that in a minor version bump between 3.6 and 3.7, so just using the working set should be "good enough" in practice.

Specify 'pip' version in requirements.txt

Please note that pip version listed in requirements.txt is going to be installed along with other requirements. So all requirements are going to be installed by old version of pip and the version specified in requirements.txt will be available afterwards.

I always do:

virtualenv /path/to/my/desired/venv/
source /path/to/my/desired/venv/bin/activate
pip install -U pip
pip install -r requirements.txt

How to make virtualenv to use the last version of distribute by default?

There was a similar question about updating pip on the python-virtualenv list. I've repeated here for convenience:

If you are using a recent virtualenv you can also use --extra-search-dir option to point to an alternate directory containing the distribute package you wish to install. This is documented here:

http://www.virtualenv.org/en/latest/index.html#the-extra-search-dir-option

User-provided extra-search-dir paths have precedence over the "builtin" search paths, so you should be able to achieve what you want

How I can make apt-get install to my virtualenv?

If you really need to do it this way, you can just copy the files that get installed globally directly into your virtualenv. For example I couldn't get pycurl working since the required libraries weren't installing, but apt-get install python-pycurl did. So I did the following:

sudo apt-get install python-pycurl
cp /usr/lib/python2.7/dist-packages/pycurl* ~/.virtualenvs/myenv/lib/python2.7/site-packages/

The install said it was adding it to /usr/lib/python2.7. So I looked in that directory for a site-packages or dist-packages with pycurl, after looking at the files I copied them into my virtualenv. You'd have to also copy any executables from bin into your virtualenv's bin directory.

Also, running a pip install -r requirements.txt successfully found pycurl in there and just skipped over it as if I had installed it via pip.

Install Python 3.6.3 in Virtualenv using pip in WIndows 10?

Pip and virtualenv are two separate tools. Pip is a package manager, you will use it to install packages into your virtual environment once it has been set up. Pip does not actually manage the virtual environment. Virtualenv is the tool that handles creating virtual environments.

First, you should check if you have virtualenv installed with virtualenv --version. If you do not have it, you will get an error that virtualenv is not found. You can use pip to install virtualenv with pip install virtualenv.

Once you have virtualenv, you can create a python 3.6 environment with virtualenv -p python3.6 /path/to/myvirtualenv. You will need an installation of python 3.6 for this command to work, so download and install python 3.6 first if you do not have it.

I believe that on windows if you don't have python 3.6 in your PATH variable, you may need to point directly to the python 3.6 installation instead with virtualenv -p /path/to/mypython3.6 /path/to/myvirtualenv.

See Virtualenv User Guide