- Published: June 10, 2016
The tipical workflow to isolate a python project consist of the following steps:
- Create a project dir
- Create a virtual environment for the project outside its directory
- virtualenvwrapper uses the variable WORKON_HOME to specify the location of new virtual environments. The default value is $HOME/.virtualenvs
Then each time you work on the project you have two alternatives:
- Manually create and activate the virtual environment for the project
- Create an instance where all the packages are installed for a specific project instead of executing those present in the Operating System, then you will need to active it each time you work in that project.
- source ~/.virtualenvs/my_project/bin/activate
- Configure a virtualenvwrapper
- it provides often used processes as scripts and defines standard environment variables and installation paths.
- Using it is as easy as select your environment with a command
- workon my_project
Create a virtual environment
Create the virtual environment (preferable in a directory outside the project)
The preferred python version to use in the new environment can also be specified.
#Create the project $ mkdir my_project; #Create the virtual environment $ virtualenv -p python3.5 ~/.virtualenvs/my_project
Use the virtual environment
To use the new environment, it should be activated. Any command executed after activating it, will use the packages installed in this virtual environment.
Console prompt will change (in most cases) to reflect this situation prepending the virtual environment name in terminal prompt.
$ source ~/.virtualenvs/my_project/bin/activate (virtualenv)$
Stop using the virtual environment
(virtualenv)$ deactivate $
Virtualenvwrapper makes it easier to perform virtualenv tasks. It is build upon the following concepts:
- The source code that needs a special virtual environment specified in a requirements file.
- The base directory for projects is specified in PROJECT_HOME.
- A Virtualenv directory
- All the virtualenvs for each project will be contained here in subdirectories.
- Specified in the variable WORKON_HOME, by default will be: $HOME/.virtualenvs
mkvirtualenv provides the same options as
virtualenv plus a few options. It creates by default the virtualenv environment in
~/.virtualenvs/<env_name> and then activates it.
Usage: mkvirtualenv [-a project_path] [-i package] [-r requirements_file] [virtualenv options] env_name
Common workflow to work on a new virtual environment using virtualenvwrapper:
Create the virtual environment
- (by default it will available in $WORKON_HOME)
The variable WORKON_HOME tells virtualenvwrapper where to place your > virtual environments. The default is $HOME/.virtualenvs. If the directory does not exist when virtualenvwrapper is loaded, it will be created automatically.
list the available environments and activate the project to work on with workon
Go to the project directory cdvirtualenv
deactivate the environment when finished working
$ mkvirtualenv myenvname New python executable in /home/marcanuy/.virtualenvs/myenvname/bin/python Installing setuptools, pip, wheel...done. #the previous created env will appear listed, along the other envs (myenvname)$ workon myenvname #changes to the associated project directory (myenvname)$ cdvirtualenv myenvname (myenvname)/opt/development/myproject$ cdsitepackages (myenvname)~/.virtualenvs/myenvname/lib/python3.5/site-packages$ cdvirtualenv #finish work (myenvname)/opt/development/myproject$ deactivate /opt/development/myproject$ _
To create a new environment having a requirements file and a specific python version: mkvirtualenv -r requirements/local.txt -p /usr/bin/python3.5 myprojectname