Related
For my package, foo, I'm using the following setup.py:
from setuptools import setup
setup(name='foo',
version='0.0.1',
description='Lol',
url='https://github.com/foo/foo',
author='legend',
author_email='lol#gmail.com',
license='GPLv3',
packages=['foo'],
install_requires=["bar"],
entry_points = {'console_scripts': ['foo = foo:main']},
keywords = ['foo'],
zip_safe=False)
When testing on my Arch system, it added the script to PATH automatically so I could just run foo on my command line and it'd run the function main() automatically. Then, I booted up a VM and tested it on Windows 7. Pip installed the package just fine, but it wasn't in my path!
Help?
setuptools, pip and easy_install don't modify the system PATH variable. The <python directory>\Scripts directory, where all of them install the script by default, is normally added to PATH by the Python installer during installation.
If the scripts folder was not added to your PATH during installation, you can fix that by running <python directory>\Tools\scripts\win_add2path.py. (See How can I find where Python is installed on Windows?)
The above sample setup.py file worked fine for me (with the Scripts directory in PATH), by the way. I tested it with
python setup.py bdist_wheel
pip install dist\foo-0.0.1-py3-none-any.whl
and
python setup.py sdist
pip install dist\foo-0.0.1.zip
Do not expect pip or easy_install to modify your PATH, their task is to install a package into current environment.
On Linux, if you use global Python environment, you are likely to need root privileges, so you typically do:
$ sudo pip install <package>
However, this is not recommended method as it spoils system-wide Python environment (imagine having two applications having a bit different requirements to the same package version and you might have a problem).
Recommended method is to use some sort of virtualenv, which allows installing python package into separate python environment, which is also easy to remove and recreate.
How I install python based scripts into system
It seems like you have custom python based script, which you want to use in your system.
For this scenario I use following method (assuming virtualenv tool is installed into system-wide python):
$ mkdir ~/apps
$ mkdir ~/apps/myutil
$ cd ~/apps/myutil
$ virtualenv .env
$ source .env/bin/activate
(.env)$ pip install <package-or-more>
Now you shall have in ~/apps/myutil/.env/bin directory installed all the script installed by pip, let us call it myscript (there can be more).
Remaining step is to make symlink from some directory which is already on PATH, e.g. into /usr/local/bin:
$ cd /usr/local/bin
$ sudo ln -s ~/apps/myutil/.env/bin/myscript
From now on, you shall be able calling command myscript even without virtualenv being activated.
Updating the script
If you need to install later version of the script:
$ cd ~/apps/myutil
$ source .env/bin/activate
(.env)$ pip install --upgrade <package-or-more>
As you have the script linked, it will automatically be available in the latest version.
naming with virtualenvwrapper
virtualenvwrapper allows you to create multiple named virtualenvs and give you easy activation and
deactivation. In such case I do the following:
$ mkvirtualenv bin-myscript
(bin-myscript)$ pip install <package-or-more>
(bin-myscript)$ which `myscript`
~/.Evns/bin-myscript/bin/myscript
(bin-myscript)$ cd /usr/local/bin
(bin-myscript)$ sudo ln -s ~/.Evns/bin-myscript/bin/myscript
Upgrade is even simpler:
$ workon bin-myscript
(bin-myscript)$ pip install --upgrade <package-or-two>
and you are done
alternative with tox
tox is great tool for automated creation of virtualenvs and testing. I use it for creating
virtualenvs in directories I like. For more information see my other SO answer
Using virtualenv, I run my projects with the default version of Python (2.7). On one project, I need to use Python 3.4.
I used brew install python3 to install it on my Mac. Now, how do I create a virtualenv that uses the new version?
e.g. sudo virtualenv envPython3
If I try:
virtualenv -p python3 test
I get:
Running virtualenv with interpreter /usr/local/bin/python3
Using base prefix '/usr/local/Cellar/python3/3.4.0_1/Frameworks/Python.framework/Versions/3.4'
New python executable in test/bin/python3.4
Also creating executable in test/bin/python
Failed to import the site module
Traceback (most recent call last):
File "/Users/user/Documents/workspace/test/test/bin/../lib/python3.4/site.py", line 67, in <module>
import os
File "/Users/user/Documents/workspace/test/test/bin/../lib/python3.4/os.py", line 634, in <module>
from _collections_abc import MutableMapping
ImportError: No module named '_collections_abc'
ERROR: The executable test/bin/python3.4 is not functioning
ERROR: It thinks sys.prefix is '/Users/user/Documents/workspace/test' (should be '/Users/user/Documents/workspace/test/test')
ERROR: virtualenv is not compatible with this system or executable
simply run
virtualenv -p python3 envname
Update after OP's edit:
There was a bug in the OP's version of virtualenv, as described here. The problem was fixed by running:
pip install --upgrade virtualenv
Python 3 has a built-in support for virtual environments - venv. It might be better to use that instead. Referring to the docs:
Creation of virtual environments is done by executing the pyvenv
script:
pyvenv /path/to/new/virtual/environment
Update for Python 3.6 and newer:
As pawciobiel correctly comments, pyvenv is deprecated as of Python 3.6 and the new way is:
python3 -m venv /path/to/new/virtual/environment
I'v tried pyenv and it's very handy for switching python versions (global, local in folder or in the virtualenv):
brew install pyenv
then install Python version you want:
pyenv install 3.5.0
and simply create virtualenv with path to needed interpreter version:
virtualenv -p /Users/johnny/.pyenv/versions/3.5.0/bin/python3.5 myenv
That's it, check the version:
. ./myenv/bin/activate && python -V
There are also plugin for pyenv pyenv-virtualenv but it didn't work for me somehow.
Install prerequisites.
sudo apt-get install python3 python3-pip virtualenvwrapper
Create a Python3 based virtual environment. Optionally enable --system-site-packages flag.
mkvirtualenv -p /usr/bin/python3 <venv-name>
Set into the virtual environment.
workon <venv-name>
Install other requirements using pip package manager.
pip install -r requirements.txt
pip install <package_name>
When working on multiple python projects simultaneously it is usually recommended to install common packages like pdbpp globally and then reuse them in virtualenvs.
Using this technique saves a lot of time spent on fetching packages and installing them, apart from consuming minimal disk space and network bandwidth.
sudo -H pip3 -v install pdbpp
mkvirtualenv -p $(which python3) --system-site-packages <venv-name>
Django specific instructions
If there are a lot of system wide python packages then it is recommended to not use --system-site-packages flag especially during development since I have noticed that it slows down Django startup a lot. I presume Django environment initialisation is manually scanning and appending all site packages from the system path which might be the reason. Even python manage.py shell becomes very slow.
Having said that experiment which option works better. Might be safe to just skip --system-site-packages flag for Django projects.
virtualenv --python=/usr/bin/python3 <name of env>
worked for me.
This is all you need, in order to run a virtual environment in python / python3
First if virtualenv not installed, run
pip3 install virtualenv
Now Run:
virtualenv -p python3 <env name> # you can specify full path instead <env_name> to install the files in a different location other than the current location
Sometime the cmd virtualenv fails, if so use this:
python3 -m virtualenv <env_name> # you can specify full path instead <env_name> to install the files in a different location other than the current location
Now activate the virtual env:
source <env_name>/bin/activate
Or:
source `pwd`/<env_name>/bin/activate
Now run
which python
You should see the full path to your dir and <env_name>/bin/python suffix
To exit the virtualenv, run:
deactivate
To troubleshoot Python location got to here
You can specify specific Version of Python while creating environment.
It's mentioned in virtualenv.py
virtualenv --python=python3.5 envname
In some cases this has to be the full path to the executable:
virtualenv --python=/Users/username/.pyenv/versions/3.6.0/bin/python3.6 envname
How -p works
parser.add_option(
'-p', '--python',
dest='python',
metavar='PYTHON_EXE',
help='The Python interpreter to use, e.g., --python=python3.5 will use the python3.5 '
'interpreter to create the new environment. The default is the interpreter that '
'virtualenv was installed with (%s)' % sys.executable)
I had the same ERROR message. tbrisker's solution did not work in my case. Instead this solved the issue:
$ python3 -m venv .env
In addition to the other answers, I recommend checking what instance of virtualenv you are executing:
which virtualenv
If this turns up something in /usr/local/bin, then it is possible - even likely - that you installed virtualenv (possibly using an instance of easy_tools or pip) without using your system's package manager (brew in OP's case). This was my problem.
Years ago - when I was even more ignorant - I had installed virtualenv and it was masking my system's package-provided virtualenv.
After removing this old, broken virtualenv, my problems went away.
The below simple commands can create a virtual env with version 3.5
apt-get install python3-venv
python3.5 -m venv <your env name>
if you want virtual env version as 3.6
python3.6 -m venv <your env name>
Python now comes with its own implementation of virtual environment, by the name of "venv". I would suggest using that, instead of virtualenv.
Quoting from venv - docs,
Deprecated since version 3.6: pyvenv was the recommended tool for
creating virtual environments for Python 3.3 and 3.4, and is
deprecated in Python 3.6.
Changed in version 3.5: The use of venv is now recommended for
creating virtual environments.
For windows, to initiate venv on some project, open cmd:
python -m venv "c:\path\to\myenv"
(Would suggest using double quote around directory path if it contains any spaces. Ex: "C:/My Dox/Spaced Directory/Something")
Once venv is set up, you will see some new folders inside your project directory. One of them would be "Scripts".
To activate or invoke venv you need:
C:\> <venv>\Scripts\activate.bat
You can deactivate a virtual environment by typing “deactivate” in your shell. With this, you are now ready to install your project specific libraries, which will reside under the folder "Lib".
================================ Edit 1 ====================================
The scenario which will be discussed below is not what originally asked, just adding this in case someone use vscode with python extension
In case, you use vs code with its python extension, you might face an issue with its pylint which points to the global installation. In this case, pylint won't be able to see the modules that are installed in your virtual environment and hence will show errors while importing.
Here is a simple method to get past this.
cd Workspace\Scripts
.\Activate.ps1
code .
We are basically activating the environment first and then invoking vs-code so that pylint starts within the environment and can see all local packages.
In python3.6 I tried
python3 -m venv myenv,
as per the documentation, but it was taking so long. So the very simple and quick command is
python -m venv yourenv
It worked for me on python3.6.
On Mac I had to do the following to get it to work.
mkvirtualenv --python=/usr/bin/python3 YourEnvNameHere
If you install python3 (brew install python3) along with virtualenv burrito, you can then do mkvirtualenv -p $(which python3) env_name
Of course, I know virtualenv burrito is just a wrapper, but it has served me well over the years, reducing some learning curves.
virtualenv --python=/usr/local/bin/python3 <VIRTUAL ENV NAME>
this will add python3
path for your virtual enviroment.
It worked for me
virtualenv --no-site-packages --distribute -p /usr/bin/python3 ~/.virtualenvs/py3
For those having troubles while working with Anaconda3 (Python 3).
You could use
conda create -n name_of_your_virtualenv python=python_version
To activate the environment ( Linux, MacOS)
source activate name_of_your_virtualenv
For Windows
activate name_of_your_virtualenv
I tried all the above stuff, it still didn't work. So as a brute force, I just re-installed the anaconda, re-installed the virtualenv... and it worked.
Amans-MacBook-Pro:~ amanmadan$ pip install virtualenv
You are using pip version 6.1.1, however version 8.1.2 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.
Collecting virtualenv
Downloading virtualenv-15.0.3-py2.py3-none-any.whl (3.5MB)
100% |████████████████████████████████| 3.5MB 114kB/s
Installing collected packages: virtualenv
Successfully installed virtualenv-15.0.3
Amans-MacBook-Pro:python amanmadan$ virtualenv my_env
New python executable in /Users/amanmadan/Documents/HadoopStuff/python/my_env/bin/python
Installing setuptools, pip, wheel...done.
Amans-MacBook-Pro:python amanmadan$
I wanted to keep python 2.7.5 as default version on Centos 7 but have python 3.6.1 in a virtual environment running alongside other virtual environments in python 2.x
I found the below link the best solution for the newest python version ( python 3.6.1)
https://www.digitalocean.com/community/tutorial_series/how-to-install-and-set-up-a-local-programming-environment-for-python-3.
It shows the steps for different platforms but the basic steps are
Install python3.x (if not present) for your platform
Install python3.x-devel for your platform
Create virtual environment in python 3.x
(for example $ python3.6 -m venv virenv_test_p3/ )
Activate the testenvironment for python 3.x
(for example source virenv_test_p3/bin/activate)
Install the packages which you want to use in your new python 3 virtual environment and which are supported ( for example pip install Django==1.11.2)
On Windows command line, the following worked for me. First find out where your python executables are located:
where python
This will output the paths to the different python.exe on your system. Here were mine:
C:\Users\carandangc\Anaconda3\python.exe
C:\Python27\python.exe
So for Python3, this was located in the first path for me, so I cd to the root folder of the application where I want to create a virtual environment folder. Then I run the following which includes the path to my Python3 executable, naming my virtual environment 'venv':
virtualenv --python=/Users/carandangc/Anaconda3/python.exe venv
Next, activate the virtual environment:
call venv\Scripts\activate.bat
Finally, install the dependencies for this virtual environment:
pip install -r requirements.txt
This requirements.txt could be populated manually if you know the libraries/modules needed for your application in the virtual environment. If you had the application running in another environment, then you can automatically produce the dependencies by running the following (cd to the application folder in the environment where it is working):
pip freeze > requirements.txt
Then once you have the requirements.txt that you have 'frozen', then you can install the requirements on another machine or clean environment with the following (after cd to the application folder):
pip install -r requirements.txt
To see your python version in the virtual environment, run:
python --version
Then voila...you have your Python3 running in your virtual environment. Output for me:
Python 3.7.2
For those of you who are using pipenv and want to install specific version:
pipenv install --python 3.6
I got the same error due to it being a conflict with miniconda3 install so when you type "which virtualenv" and if you've installed miniconda and it's pointing to that install you can either remove it (if your like me and haven't moved to it yet) or change your environment variable to point to the install you want.
Short Question
What is the proper way to install pip, virtualenv, and distribute?
Background
In my answer to SO question 4314376, I recommended using ez_setup so that you could then install pip and virtualenv as follows:
curl -O http://peak.telecommunity.com/dist/ez_setup.py
sudo python ez_setup.py
sudo easy_install pip
sudo pip install virtualenv
I originally pulled these instructions from Jesse Noller's blog post So you want to use Python on the Mac?. I like the idea of keeping a clean global site-packages directory, so the only other packages I install there are virtualenvwrapper and distribute. (I recently added distribute to my toolbox because of this Python public service announcement. To install these two packages, I used:
sudo pip install virtualenvwrapper
curl -O http://python-distribute.org/distribute_setup.py
sudo python distribute_setup.py
No more setuptools and easy_install
To really follow that Python public service announcement, on a fresh Python install, I would do the following:
curl -O http://python-distribute.org/distribute_setup.py
sudo python distribute_setup.py
sudo easy_install pip
sudo pip install virtualenv
sudo pip install virtualenvwrapper
Glyph's Rebuke
In a comment to my answer to SO question 4314376, SO user Glyph stated:
NO. NEVER EVER do sudo python setup.py install whatever. Write a ~/.pydistutils.cfg that puts your pip installation into ~/.local or something. Especially files named ez_setup.py tend to suck down newer versions of things like setuptools and easy_install, which can potentially break other things on your operating system.
Back to the short question
So Glyph's response leads me to my original question:
What is the proper way to install pip, virtualenv, and distribute?
You can do this without installing anything into python itself.
You don't need sudo or any privileges.
You don't need to edit any files.
Install virtualenv into a bootstrap virtual environment. Use the that virtual environment to create more. Since virtualenv ships with pip and distribute, you get everything from one install.
Download virtualenv:
http://pypi.python.org/pypi/virtualenv
https://pypi.python.org/packages/source/v/virtualenv/virtualenv-12.0.7.tar.gz
(or whatever is the latest version!)
Unpack the source tarball
Use the unpacked tarball to create a clean virtual environment. This virtual environment will be used to "bootstrap" others. All of your virtual environments will automatically contain pip and distribute.
Using pip, install virtualenv into that bootstrap environment.
Use that bootstrap environment to create more!
Here is an example in bash:
# Select current version of virtualenv:
VERSION=12.0.7
# Name your first "bootstrap" environment:
INITIAL_ENV=bootstrap
# Set to whatever python interpreter you want for your first environment:
PYTHON=$(which python)
URL_BASE=https://pypi.python.org/packages/source/v/virtualenv
# --- Real work starts here ---
curl -O $URL_BASE/virtualenv-$VERSION.tar.gz
tar xzf virtualenv-$VERSION.tar.gz
# Create the first "bootstrap" environment.
$PYTHON virtualenv-$VERSION/virtualenv.py $INITIAL_ENV
# Don't need this anymore.
rm -rf virtualenv-$VERSION
# Install virtualenv into the environment.
$INITIAL_ENV/bin/pip install virtualenv-$VERSION.tar.gz
Now you can use your "bootstrap" environment to create more:
# Create a second environment from the first:
$INITIAL_ENV/bin/virtualenv py-env1
# Create more:
$INITIAL_ENV/bin/virtualenv py-env2
Go nuts!
Note
This assumes you are not using a really old version of virtualenv.
Old versions required the flags --no-site-packges (and depending on the version of Python, --distribute). Now you can create your bootstrap environment with just python virtualenv.py path-to-bootstrap or python3 virtualenv.py path-to-bootstrap.
I think Glyph means do something like this:
Create a directory ~/.local, if it doesn't already exist.
In your ~/.bashrc, ensure that ~/.local/bin is on PATH and that ~/.local is on PYTHONPATH.
Create a file ~/.pydistutils.cfg which contains
[install]
prefix=~/.local
It's a standard ConfigParser-format file.
Download distribute_setup.py and run python distribute_setup.py (no sudo). If it complains about a non-existing site-packages directory, create it manually:
mkdir -p ~/.local/lib/python2.7/site-packages/
Run which easy_install to verify that it's coming from ~/.local/bin
Run pip install virtualenv
Run pip install virtualenvwrapper
Create a virtual env containing folder, say ~/.virtualenvs
In ~/.bashrc add
export WORKON_HOME
source ~/.local/bin/virtualenvwrapper.sh
That's it, no use of sudo at all and your Python environment is in ~/.local, completely separate from the OS's Python. Disclaimer: Not sure how compatible virtualenvwrapper is in this scenario - I couldn't test it on my system :-)
If you follow the steps advised in several tutorials I linked in this answer, you
can get the desired effect without the somewhat complicated "manual" steps in Walker's and Vinay's answers. If you're on Ubuntu:
sudo apt-get install python-pip python-dev
The equivalent is achieved in OS X by using homebrew to install python (more details here).
brew install python
With pip installed, you can use it to get the remaining packages (you can omit sudo in OS X, as you're using your local python installation).
sudo pip install virtualenvwrapper
(these are the only packages you need installed globally and I doubt that it will clash with anything system-level from the OS. If you want to be super-safe, you can keep the distro's versions sudo apt-get install virtualenvwrapper)
Note: in Ubuntu 14.04 I receive some errors with pip install, so I use pip3 install virtualenv virtualenvwrapper and add VIRTUALENVWRAPPER_PYTHON=/usr/bin/python3 to my .bashrc/.zshrc file.
You then append to your .bashrc file
export WORKON_HOME
source /usr/local/bin/virtualenvwrapper.sh
and source it
. ~/.bashrc
This is basically it. Now the only decision is whether you want to create a virtualenv to include system-level packages
mkvirtualenv --system-site-packages foo
where your existing system packages don't have to be reinstalled, they are symlinked to the system interpreter's versions. Note: you can still install new packages and upgrade existing included-from-system packages without sudo - I tested it and it works without any disruptions of the system interpreter.
kermit#hocus-pocus:~$ sudo apt-get install python-pandas
kermit#hocus-pocus:~$ mkvirtualenv --system-site-packages s
(s)kermit#hocus-pocus:~$ pip install --upgrade pandas
(s)kermit#hocus-pocus:~$ python -c "import pandas; print(pandas.__version__)"
0.10.1
(s)kermit#hocus-pocus:~$ deactivate
kermit#hocus-pocus:~$ python -c "import pandas; print(pandas.__version__)"
0.8.0
The alternative, if you want a completely separated environment, is
mkvirtualenv --no-site-packages bar
or given that this is the default option, simply
mkvirtualenv bar
The result is that you have a new virtualenv where you can freely and sudolessly install your favourite packages
pip install flask
Python 3.4 onward
Python 3.3 adds the venv module, and Python 3.4 adds the ensurepip module. This makes bootstrapping pip as easy as:
python -m ensurepip
Perhaps preceded by a call to venv to do so inside a virtual environment.
Guaranteed pip is described in PEP 453.
On Ubuntu:
sudo apt-get install python-virtualenv
The package python-pip is a dependency, so it will be installed as well.
I made this procedure for us to use at work.
cd ~
curl -s https://pypi.python.org/packages/source/p/pip/pip-1.3.1.tar.gz | tar xvz
cd pip-1.3.1
python setup.py install --user
cd ~
rm -rf pip-1.3.1
$HOME/.local/bin/pip install --user --upgrade pip distribute virtualenvwrapper
# Might want these three in your .bashrc
export PATH=$PATH:$HOME/.local/bin
export VIRTUALENVWRAPPER_VIRTUALENV_ARGS="--distribute"
source $HOME/.local/bin/virtualenvwrapper.sh
mkvirtualenv mypy
workon mypy
pip install --upgrade distribute
pip install pudb # Or whatever other nice package you might want.
Key points for the security minded:
curl does ssl validation. wget doesn't.
Starting from pip 1.3.1, pip also does ssl validation.
Fewer users can upload the pypi tarball than a github tarball.
Update: As of July 2013 this project is no longer maintained. The author suggests using pyenv. (pyenv does not have built-in support for virtualenv, but plays nice with it.)
Pythonbrew is a version manager for python and comes with support for virtualenv.
After installing pythonbrew and a python-version using venvs is really easy:
# Initializes the virtualenv
pythonbrew venv init
# Create a virtual/sandboxed environment
pythonbrew venv create mycoolbundle
# Use it
pythonbrew venv use mycoolbundle
I've had various problems (see below) installing upgraded SSL modules, even inside a virtualenv, on top of older OS-provided Python versions, so I now use pyenv.
pyenv makes it very easy to install new Python versions and supports virtualenvs. Getting started is much easier than the recipes for virtualenv listed in other answers:
On Mac, type brew install pyenv and on Linux, use pyenv-installer
this gets you built-in virtualenv support as well as Python version switching (if required)
works well with Python 2 or 3, can have many versions installed at once
This works very well to insulate the "new Python" version and virtualenv from system Python. Because you can easily use a more recent Python (post 2.7.9), the SSL modules are already upgraded, and of course like any modern virtualenv setup you are insulated from the system Python modules.
A couple of nice tutorials:
Using pyenv and virtualenv - when selecting a Python version, it's easier to use pyenv global 3.9.1 (global to current user) or pyenv local 3.6.3 (local to current directory).
pyenv basics and use with virtualenv
The pyenv-virtualenv plugin is now built in - type pyenv commands | grep virtualenv to check. I wouldn't use the pyenv-virtualenvwrapper plugin to start with - see how you get on with pyenv-virtualenv which is more integrated into pyenv, as this covers most of what virtualenvwrapper does.
pyenv is modelled on rbenv (a good tool for Ruby version switching) and its only dependency is bash.
pyenv is unrelated to the very similarly named pyvenv - that is a virtualenv equivalent that's part of recent Python 3 versions, and doesn't handle Python version switching
Caveats
Two warnings about pyenv:
It only works from a bash or similar shell - or more specifically, the pyenv-virtualenv plugin doesn't like dash, which is /bin/sh on Ubuntu or Debian.
It must be run from an interactive login shell (e.g. bash --login using a terminal), which is not always easy to achieve with automation tools such as Ansible.
Hence pyenv is best for interactive use, and less good for scripting servers.
Older distributions - SSL module problems
One reason to use pyenv was that there were often problems with upgrading Python SSL modules when using older system-provided Python versions. This may be less of a problem now that current Linux distributions support Python 3.x.
There is no problem to do sudo python setup.py install, if you're sure it's what you want to do.
The difference is that it will use the site-packages directory of your OS as a destination for .py files to be copied.
so, if you want pip to be accessible os wide, that's probably the way to go. I do not say that others way are bad, but this is probably fair enough.
Install ActivePython. It includes pip, virtualenv and Distribute.
I came across the same problem recently. I’m becoming more partial to the “always use a virtualenv” mindset, so my problem was to install virtualenv with pip without installing distribute to my global or user site-packages directory. To do this, I manually downloaded distribute, pip and virtualenv, and for each one I ran “python setup.py install --prefix ~/.local/python-private” (with a temporary setting of PYTHONPATH=~/.local/python-private) so that setup scripts were able to find distribute). I’ve moved the virtualenv script to another directory I have on my PATH and edited it so that the distribute and virtualenv modules can be found on sys.path. Tada: I did not install anything to /usr, /usr/local or my user site-packages dir, but I can run virtualenv anywhere, and in that virtualenv I get pip.
The good news is if you have installed python3.4, pyvenv is already been installed. So, Just
pyvenv project_dir
source project_dir/bin/activate
python --version
python 3.4.*
Now in this virtual env, you can use pip to install modules for this project.
Leave this virtual env , just
deactivate
You can do this without installing anything into python itself.
You don't need sudo or any privileges.
You don't need to find the latest version of a virtualenv tar file
You don't need to edit version info in a bash script to keep things up-to-date.
You don't need curl/wget or tar installed, nor pip or easy_install
this works for 2.7 as well as for 3.X
Save the following to /tmp/initvenv.py:
from __future__ import print_function
import os, sys, shutil, tempfile, subprocess, tarfile, hashlib
try:
from urllib2 import urlopen
except ImportError:
from urllib.request import urlopen
tmp_dir = tempfile.mkdtemp(prefix='initvenv_')
try:
# read the latest version from PyPI
f = urlopen("https://pypi.python.org/pypi/virtualenv/")
# retrieve the .tar.gz file
tar_found = False
url = None
sha256 = None
for line in f.read().splitlines():
if isinstance(line, bytes):
line = line.decode('utf-8')
if tar_found:
if 'sha256' in line:
sha256 = line.split('data-clipboard-text')[1].split('"')[1]
break
continue
if not tar_found and 'tar.gz">' not in line:
continue
tar_found = True
for url in line.split('"'):
if url.startswith('https'):
break
else:
print('tar.gz not found')
sys.exit(1)
file_name = url.rsplit('/', 1)[1]
print(file_name)
os.chdir(tmp_dir)
data = urlopen(url).read()
data_sha256 = hashlib.sha256(data).hexdigest()
if sha256 != data_sha256:
print('sha256 not correct')
print(sha256)
print(data_sha256)
sys.exit(1)
with open(file_name, 'wb') as fp:
fp.write(data)
tar = tarfile.open(file_name)
tar.extractall()
tar.close()
os.chdir(file_name.replace('.tar.gz', ''))
print(subprocess.check_output([sys.executable, 'virtualenv.py'] +
[sys.argv[1]]).decode('utf-8'), end='')
if len(sys.argv) > 2:
print(subprocess.check_output([
os.path.join(sys.argv[1], 'bin', 'pip'), 'install', 'virtualenv'] +
sys.argv[2:]).decode('utf-8'), end='')
except:
raise
finally:
shutil.rmtree(tmp_dir) # always clean up
and use it as
python_binary_to_use_in_venv /tmp/initvenv.py your_venv_name [optional packages]
e.g. (if you really need the distribute compatibility layer for setuptools)
python /tmp/initvenv.py venv distribute
Please note that, with older python versions, this might give you InsecurePlatformWarnings¹.
Once you have your virtualenv (name e.g. venv) you can setup another virtualenv by using the virtualenv just installed:
venv/bin/virtualenv venv2
###virtualenvwrapper
I recommend taking a look at virtualenvwrapper as well, after a one time setup:
% /opt/python/2.7.10/bin/python /tmp/initvenv.py venv virtualenvwrapper
and activation (can be done from your login script):
% source venv/bin/virtualenvwrapper.sh
you can do things like:
% mktmpenv
New python executable in tmp-17bdc3054a46b2b/bin/python
Installing setuptools, pip, wheel...done.
This is a temporary environment. It will be deleted when you run 'deactivate'.
(tmp-17bdc3054a46b2b)%
¹ I have not found a way to suppress the warning. It could be solved in pip and/or request, but the developers point to each other as the cause. I got the, often non-realistic, recommendation to upgrade the python version I was using to the latest version. I am sure this would break e.g my Linux Mint 17 install. Fortunately pip caches packages, so the Warning is made
only once per package install.
There are good instructions on the Virtualenv official site. https://pypi.python.org/pypi/virtualenv
Basically what I did, is install pip with sudo easy_install pip, then used sudo pip install virtualenv then created an environment with: virtualenv my_env (name it what you want), following that I did: virtualenv --distribute my_env; which installed distribute and pip in my virtualenv.
Again, follow the instruction on the virtualenv page.
Kind of a hassle, coming from Ruby ;P
Here is a nice way to install virtualenvwrapper(update of this).
Download virtualenv-1.11.4 (you can find latest at here), Unzip it, open terminal
# Create a bootstrapenv and activate it:
$ cd ~
$ python <path to unzipped folder>/virtualenv.py bootstrapenv
$ source bootstrapenv/bin/activate
# Install virtualenvwrapper:
$ pip install virtualenvwrapper
$ mkdir -p ~/bootstrapenv/Envs
# append it to file `.bashrc`
$ vi ~/.bashrc
source ~/bootstrapenv/bin/activate
export WORKON_HOME=~/bootstrapenv/Envs
source ~/bootstrapenv/bin/virtualenvwrapper.sh
# run it now.
$ source ~/.bashrc
That is it, now you can use mkvirtualenv env1, lsvirtualenv ..etc
Note: you can delete virtualenv-1.11.4 and virtualenv-1.11.4.zip from Downloads folders.
I've installed py26 using macports. I want to install a separate module that isn't on Macports. It gets installed in to my default OSX installation. How do I point my install to my macport installation.
First make sure your PATH is set up properly for MacPorts Python. You need to ensure that the Python framework bin directory is on it along with the normal MacPorts bin directories:
$ export PATH=opt/local/Library/Frameworks/Python.framework/Versions/2.6/bin:/opt/local/bin:/opt/local/sbin:$PATH
If the package is installed by running a command like python setup.py ... then you should be all set. You could be extra sure by using an absolute path to the MacPorts Python:
$ sudo /opt/local/bin/python2.6 setup.py ...
If the package is installed with an easy_install command, make sure you have installed a version of easy_install for the MacPorts Python. The simplest way to do that:
$ sudo port install py26-distribute # setuptools replacement, provides easy_install
$ sudo /opt/local/bin/easy_install-2.6 ...
Put py26 on your path. In your .bash_profile for instance this should work
export PATH=/opt/local/bin:/opt/local/sbin:$PATH
don't forget to source at the end from the commandline
. ~/.bash_profile
Install the "python_select" port. It will then be easier for you to install packages for your selected python version.
See the discussion in What is the best way to install python 2 on OS X?
Short Question
What is the proper way to install pip, virtualenv, and distribute?
Background
In my answer to SO question 4314376, I recommended using ez_setup so that you could then install pip and virtualenv as follows:
curl -O http://peak.telecommunity.com/dist/ez_setup.py
sudo python ez_setup.py
sudo easy_install pip
sudo pip install virtualenv
I originally pulled these instructions from Jesse Noller's blog post So you want to use Python on the Mac?. I like the idea of keeping a clean global site-packages directory, so the only other packages I install there are virtualenvwrapper and distribute. (I recently added distribute to my toolbox because of this Python public service announcement. To install these two packages, I used:
sudo pip install virtualenvwrapper
curl -O http://python-distribute.org/distribute_setup.py
sudo python distribute_setup.py
No more setuptools and easy_install
To really follow that Python public service announcement, on a fresh Python install, I would do the following:
curl -O http://python-distribute.org/distribute_setup.py
sudo python distribute_setup.py
sudo easy_install pip
sudo pip install virtualenv
sudo pip install virtualenvwrapper
Glyph's Rebuke
In a comment to my answer to SO question 4314376, SO user Glyph stated:
NO. NEVER EVER do sudo python setup.py install whatever. Write a ~/.pydistutils.cfg that puts your pip installation into ~/.local or something. Especially files named ez_setup.py tend to suck down newer versions of things like setuptools and easy_install, which can potentially break other things on your operating system.
Back to the short question
So Glyph's response leads me to my original question:
What is the proper way to install pip, virtualenv, and distribute?
You can do this without installing anything into python itself.
You don't need sudo or any privileges.
You don't need to edit any files.
Install virtualenv into a bootstrap virtual environment. Use the that virtual environment to create more. Since virtualenv ships with pip and distribute, you get everything from one install.
Download virtualenv:
http://pypi.python.org/pypi/virtualenv
https://pypi.python.org/packages/source/v/virtualenv/virtualenv-12.0.7.tar.gz
(or whatever is the latest version!)
Unpack the source tarball
Use the unpacked tarball to create a clean virtual environment. This virtual environment will be used to "bootstrap" others. All of your virtual environments will automatically contain pip and distribute.
Using pip, install virtualenv into that bootstrap environment.
Use that bootstrap environment to create more!
Here is an example in bash:
# Select current version of virtualenv:
VERSION=12.0.7
# Name your first "bootstrap" environment:
INITIAL_ENV=bootstrap
# Set to whatever python interpreter you want for your first environment:
PYTHON=$(which python)
URL_BASE=https://pypi.python.org/packages/source/v/virtualenv
# --- Real work starts here ---
curl -O $URL_BASE/virtualenv-$VERSION.tar.gz
tar xzf virtualenv-$VERSION.tar.gz
# Create the first "bootstrap" environment.
$PYTHON virtualenv-$VERSION/virtualenv.py $INITIAL_ENV
# Don't need this anymore.
rm -rf virtualenv-$VERSION
# Install virtualenv into the environment.
$INITIAL_ENV/bin/pip install virtualenv-$VERSION.tar.gz
Now you can use your "bootstrap" environment to create more:
# Create a second environment from the first:
$INITIAL_ENV/bin/virtualenv py-env1
# Create more:
$INITIAL_ENV/bin/virtualenv py-env2
Go nuts!
Note
This assumes you are not using a really old version of virtualenv.
Old versions required the flags --no-site-packges (and depending on the version of Python, --distribute). Now you can create your bootstrap environment with just python virtualenv.py path-to-bootstrap or python3 virtualenv.py path-to-bootstrap.
I think Glyph means do something like this:
Create a directory ~/.local, if it doesn't already exist.
In your ~/.bashrc, ensure that ~/.local/bin is on PATH and that ~/.local is on PYTHONPATH.
Create a file ~/.pydistutils.cfg which contains
[install]
prefix=~/.local
It's a standard ConfigParser-format file.
Download distribute_setup.py and run python distribute_setup.py (no sudo). If it complains about a non-existing site-packages directory, create it manually:
mkdir -p ~/.local/lib/python2.7/site-packages/
Run which easy_install to verify that it's coming from ~/.local/bin
Run pip install virtualenv
Run pip install virtualenvwrapper
Create a virtual env containing folder, say ~/.virtualenvs
In ~/.bashrc add
export WORKON_HOME
source ~/.local/bin/virtualenvwrapper.sh
That's it, no use of sudo at all and your Python environment is in ~/.local, completely separate from the OS's Python. Disclaimer: Not sure how compatible virtualenvwrapper is in this scenario - I couldn't test it on my system :-)
If you follow the steps advised in several tutorials I linked in this answer, you
can get the desired effect without the somewhat complicated "manual" steps in Walker's and Vinay's answers. If you're on Ubuntu:
sudo apt-get install python-pip python-dev
The equivalent is achieved in OS X by using homebrew to install python (more details here).
brew install python
With pip installed, you can use it to get the remaining packages (you can omit sudo in OS X, as you're using your local python installation).
sudo pip install virtualenvwrapper
(these are the only packages you need installed globally and I doubt that it will clash with anything system-level from the OS. If you want to be super-safe, you can keep the distro's versions sudo apt-get install virtualenvwrapper)
Note: in Ubuntu 14.04 I receive some errors with pip install, so I use pip3 install virtualenv virtualenvwrapper and add VIRTUALENVWRAPPER_PYTHON=/usr/bin/python3 to my .bashrc/.zshrc file.
You then append to your .bashrc file
export WORKON_HOME
source /usr/local/bin/virtualenvwrapper.sh
and source it
. ~/.bashrc
This is basically it. Now the only decision is whether you want to create a virtualenv to include system-level packages
mkvirtualenv --system-site-packages foo
where your existing system packages don't have to be reinstalled, they are symlinked to the system interpreter's versions. Note: you can still install new packages and upgrade existing included-from-system packages without sudo - I tested it and it works without any disruptions of the system interpreter.
kermit#hocus-pocus:~$ sudo apt-get install python-pandas
kermit#hocus-pocus:~$ mkvirtualenv --system-site-packages s
(s)kermit#hocus-pocus:~$ pip install --upgrade pandas
(s)kermit#hocus-pocus:~$ python -c "import pandas; print(pandas.__version__)"
0.10.1
(s)kermit#hocus-pocus:~$ deactivate
kermit#hocus-pocus:~$ python -c "import pandas; print(pandas.__version__)"
0.8.0
The alternative, if you want a completely separated environment, is
mkvirtualenv --no-site-packages bar
or given that this is the default option, simply
mkvirtualenv bar
The result is that you have a new virtualenv where you can freely and sudolessly install your favourite packages
pip install flask
Python 3.4 onward
Python 3.3 adds the venv module, and Python 3.4 adds the ensurepip module. This makes bootstrapping pip as easy as:
python -m ensurepip
Perhaps preceded by a call to venv to do so inside a virtual environment.
Guaranteed pip is described in PEP 453.
On Ubuntu:
sudo apt-get install python-virtualenv
The package python-pip is a dependency, so it will be installed as well.
I made this procedure for us to use at work.
cd ~
curl -s https://pypi.python.org/packages/source/p/pip/pip-1.3.1.tar.gz | tar xvz
cd pip-1.3.1
python setup.py install --user
cd ~
rm -rf pip-1.3.1
$HOME/.local/bin/pip install --user --upgrade pip distribute virtualenvwrapper
# Might want these three in your .bashrc
export PATH=$PATH:$HOME/.local/bin
export VIRTUALENVWRAPPER_VIRTUALENV_ARGS="--distribute"
source $HOME/.local/bin/virtualenvwrapper.sh
mkvirtualenv mypy
workon mypy
pip install --upgrade distribute
pip install pudb # Or whatever other nice package you might want.
Key points for the security minded:
curl does ssl validation. wget doesn't.
Starting from pip 1.3.1, pip also does ssl validation.
Fewer users can upload the pypi tarball than a github tarball.
Update: As of July 2013 this project is no longer maintained. The author suggests using pyenv. (pyenv does not have built-in support for virtualenv, but plays nice with it.)
Pythonbrew is a version manager for python and comes with support for virtualenv.
After installing pythonbrew and a python-version using venvs is really easy:
# Initializes the virtualenv
pythonbrew venv init
# Create a virtual/sandboxed environment
pythonbrew venv create mycoolbundle
# Use it
pythonbrew venv use mycoolbundle
I've had various problems (see below) installing upgraded SSL modules, even inside a virtualenv, on top of older OS-provided Python versions, so I now use pyenv.
pyenv makes it very easy to install new Python versions and supports virtualenvs. Getting started is much easier than the recipes for virtualenv listed in other answers:
On Mac, type brew install pyenv and on Linux, use pyenv-installer
this gets you built-in virtualenv support as well as Python version switching (if required)
works well with Python 2 or 3, can have many versions installed at once
This works very well to insulate the "new Python" version and virtualenv from system Python. Because you can easily use a more recent Python (post 2.7.9), the SSL modules are already upgraded, and of course like any modern virtualenv setup you are insulated from the system Python modules.
A couple of nice tutorials:
Using pyenv and virtualenv - when selecting a Python version, it's easier to use pyenv global 3.9.1 (global to current user) or pyenv local 3.6.3 (local to current directory).
pyenv basics and use with virtualenv
The pyenv-virtualenv plugin is now built in - type pyenv commands | grep virtualenv to check. I wouldn't use the pyenv-virtualenvwrapper plugin to start with - see how you get on with pyenv-virtualenv which is more integrated into pyenv, as this covers most of what virtualenvwrapper does.
pyenv is modelled on rbenv (a good tool for Ruby version switching) and its only dependency is bash.
pyenv is unrelated to the very similarly named pyvenv - that is a virtualenv equivalent that's part of recent Python 3 versions, and doesn't handle Python version switching
Caveats
Two warnings about pyenv:
It only works from a bash or similar shell - or more specifically, the pyenv-virtualenv plugin doesn't like dash, which is /bin/sh on Ubuntu or Debian.
It must be run from an interactive login shell (e.g. bash --login using a terminal), which is not always easy to achieve with automation tools such as Ansible.
Hence pyenv is best for interactive use, and less good for scripting servers.
Older distributions - SSL module problems
One reason to use pyenv was that there were often problems with upgrading Python SSL modules when using older system-provided Python versions. This may be less of a problem now that current Linux distributions support Python 3.x.
There is no problem to do sudo python setup.py install, if you're sure it's what you want to do.
The difference is that it will use the site-packages directory of your OS as a destination for .py files to be copied.
so, if you want pip to be accessible os wide, that's probably the way to go. I do not say that others way are bad, but this is probably fair enough.
Install ActivePython. It includes pip, virtualenv and Distribute.
I came across the same problem recently. I’m becoming more partial to the “always use a virtualenv” mindset, so my problem was to install virtualenv with pip without installing distribute to my global or user site-packages directory. To do this, I manually downloaded distribute, pip and virtualenv, and for each one I ran “python setup.py install --prefix ~/.local/python-private” (with a temporary setting of PYTHONPATH=~/.local/python-private) so that setup scripts were able to find distribute). I’ve moved the virtualenv script to another directory I have on my PATH and edited it so that the distribute and virtualenv modules can be found on sys.path. Tada: I did not install anything to /usr, /usr/local or my user site-packages dir, but I can run virtualenv anywhere, and in that virtualenv I get pip.
The good news is if you have installed python3.4, pyvenv is already been installed. So, Just
pyvenv project_dir
source project_dir/bin/activate
python --version
python 3.4.*
Now in this virtual env, you can use pip to install modules for this project.
Leave this virtual env , just
deactivate
You can do this without installing anything into python itself.
You don't need sudo or any privileges.
You don't need to find the latest version of a virtualenv tar file
You don't need to edit version info in a bash script to keep things up-to-date.
You don't need curl/wget or tar installed, nor pip or easy_install
this works for 2.7 as well as for 3.X
Save the following to /tmp/initvenv.py:
from __future__ import print_function
import os, sys, shutil, tempfile, subprocess, tarfile, hashlib
try:
from urllib2 import urlopen
except ImportError:
from urllib.request import urlopen
tmp_dir = tempfile.mkdtemp(prefix='initvenv_')
try:
# read the latest version from PyPI
f = urlopen("https://pypi.python.org/pypi/virtualenv/")
# retrieve the .tar.gz file
tar_found = False
url = None
sha256 = None
for line in f.read().splitlines():
if isinstance(line, bytes):
line = line.decode('utf-8')
if tar_found:
if 'sha256' in line:
sha256 = line.split('data-clipboard-text')[1].split('"')[1]
break
continue
if not tar_found and 'tar.gz">' not in line:
continue
tar_found = True
for url in line.split('"'):
if url.startswith('https'):
break
else:
print('tar.gz not found')
sys.exit(1)
file_name = url.rsplit('/', 1)[1]
print(file_name)
os.chdir(tmp_dir)
data = urlopen(url).read()
data_sha256 = hashlib.sha256(data).hexdigest()
if sha256 != data_sha256:
print('sha256 not correct')
print(sha256)
print(data_sha256)
sys.exit(1)
with open(file_name, 'wb') as fp:
fp.write(data)
tar = tarfile.open(file_name)
tar.extractall()
tar.close()
os.chdir(file_name.replace('.tar.gz', ''))
print(subprocess.check_output([sys.executable, 'virtualenv.py'] +
[sys.argv[1]]).decode('utf-8'), end='')
if len(sys.argv) > 2:
print(subprocess.check_output([
os.path.join(sys.argv[1], 'bin', 'pip'), 'install', 'virtualenv'] +
sys.argv[2:]).decode('utf-8'), end='')
except:
raise
finally:
shutil.rmtree(tmp_dir) # always clean up
and use it as
python_binary_to_use_in_venv /tmp/initvenv.py your_venv_name [optional packages]
e.g. (if you really need the distribute compatibility layer for setuptools)
python /tmp/initvenv.py venv distribute
Please note that, with older python versions, this might give you InsecurePlatformWarnings¹.
Once you have your virtualenv (name e.g. venv) you can setup another virtualenv by using the virtualenv just installed:
venv/bin/virtualenv venv2
###virtualenvwrapper
I recommend taking a look at virtualenvwrapper as well, after a one time setup:
% /opt/python/2.7.10/bin/python /tmp/initvenv.py venv virtualenvwrapper
and activation (can be done from your login script):
% source venv/bin/virtualenvwrapper.sh
you can do things like:
% mktmpenv
New python executable in tmp-17bdc3054a46b2b/bin/python
Installing setuptools, pip, wheel...done.
This is a temporary environment. It will be deleted when you run 'deactivate'.
(tmp-17bdc3054a46b2b)%
¹ I have not found a way to suppress the warning. It could be solved in pip and/or request, but the developers point to each other as the cause. I got the, often non-realistic, recommendation to upgrade the python version I was using to the latest version. I am sure this would break e.g my Linux Mint 17 install. Fortunately pip caches packages, so the Warning is made
only once per package install.
There are good instructions on the Virtualenv official site. https://pypi.python.org/pypi/virtualenv
Basically what I did, is install pip with sudo easy_install pip, then used sudo pip install virtualenv then created an environment with: virtualenv my_env (name it what you want), following that I did: virtualenv --distribute my_env; which installed distribute and pip in my virtualenv.
Again, follow the instruction on the virtualenv page.
Kind of a hassle, coming from Ruby ;P
Here is a nice way to install virtualenvwrapper(update of this).
Download virtualenv-1.11.4 (you can find latest at here), Unzip it, open terminal
# Create a bootstrapenv and activate it:
$ cd ~
$ python <path to unzipped folder>/virtualenv.py bootstrapenv
$ source bootstrapenv/bin/activate
# Install virtualenvwrapper:
$ pip install virtualenvwrapper
$ mkdir -p ~/bootstrapenv/Envs
# append it to file `.bashrc`
$ vi ~/.bashrc
source ~/bootstrapenv/bin/activate
export WORKON_HOME=~/bootstrapenv/Envs
source ~/bootstrapenv/bin/virtualenvwrapper.sh
# run it now.
$ source ~/.bashrc
That is it, now you can use mkvirtualenv env1, lsvirtualenv ..etc
Note: you can delete virtualenv-1.11.4 and virtualenv-1.11.4.zip from Downloads folders.