VIRTUALENVWRAPPER(1)
π virtualenvwrapper(1): the manual, but make it iconic π
β¨ NAME β¨
virtualenvwrapper, a set of wrappers that help you manage your python virtualenvs π
Everything below gets typed straight into the Terminal command line, bestie π»
πΈ MANAGING ENVIRONMENTS πΈ
π§ mkvirtualenv
Okay so mkvirtualenv creates a brand new environment inside your WORKON_HOME β¨
Syntax:
mkvirtualenv [-a project_path] [-i package] [-r requirements_file] [virtualenv options] ENVNAME
All options except -a, -i, -r, and -h get passed straight through to virtualenv. Once it's made, the new environment is automatically activated, so you're already in it π«Ά
$ workon
$ mkvirtualenv mynewenv
New python executable in mynewenv/bin/python
Installing setuptools.............................................
..................................................................
..................................................................
done.
(mynewenv)$ workon
mynewenv
(mynewenv)$
-aβ link an existing project directory to your new environment so everything's one vibe π-iβ install one or more packages after the environment is created. Repeat the option to add more π¦-rβ point it at a text file listing the packages you want. The value gets passed topip -rfor installing π
SEE ALSO π¦
scripts-premkvirtualenvscripts-postmkvirtualenv- requirements file format
π mktmpenv
Same energy as mkvirtualenv, but for a throwaway environment inside WORKON_HOME π«§
Syntax:
mktmpenv [(-c|--cd)|(-n|--no-cd)] [VIRTUALENV_OPTIONS]
No naming stress here, because a unique virtualenv name gets generated for you automatically π
If you use -c or --cd, the working directory switches to the virtualenv directory during the post-activate phase. This happens no matter what VIRTUALENVWRAPPER_WORKON_CD is set to.
If you use -n or --no-cd, the working directory stays put during the post-activate phase, again no matter what VIRTUALENVWRAPPER_WORKON_CD says.
$ mktmpenv
Using real prefix '/Library/Frameworks/Python.framework/Versions/2.7'
New python executable in 1e513ac6-616e-4d56-9aa5-9d0a3b305e20/bin/python
Overwriting 1e513ac6-616e-4d56-9aa5-9d0a3b305e20/lib/python2.7/distutils/__init__.py
with new content
Installing setuptools...............................................
....................................................................
.................................................................done.
This is a temporary environment. It will be deleted when deactivated.
(1e513ac6-616e-4d56-9aa5-9d0a3b305e20) $
π lsvirtualenv
Lists all of your environments. The main character list π
Syntax:
lsvirtualenv [-b] [-l] [-h]
-bβ Brief mode, turns off the verbose output π€«-lβ Long mode, turns the verbose output on. This is the default π-hβ prints the help forlsvirtualenvπ
SEE ALSO π¦
scripts-get_env_details
π showvirtualenv
Shows the details for one single virtualenv, so you can stalk it properly π
Syntax:
showvirtualenv [env]
SEE ALSO π¦
scripts-get_env_details
π§Ή rmvirtualenv
Removes an environment from WORKON_HOME. Bye bye π
Syntax:
rmvirtualenv ENVNAME
You have to use deactivate before removing the environment you're currently in. Don't be that person π
(mynewenv)$ deactivate
$ rmvirtualenv mynewenv
$ workon
$
SEE ALSO π¦
scripts-prermvirtualenvscripts-postrmvirtualenv
π― cpvirtualenv
Duplicates an existing virtualenv. The source can be one that virtualenvwrapper already manages, or an external environment that was created somewhere else πͺ
WARNING: Copying virtual environments is not well supported π¨ Each virtualenv has path information hard-coded into it, and there may be cases where the copy code doesn't realize it needs to update a particular file. Use with caution, bestie!
Syntax:
cpvirtualenv ENVNAME [TARGETENVNAME]
NOTE: A target environment name is required when you're duplicating within WORKON_HOME. You can skip it when importing external environments, though, and if you do, the new environment gets the same name as the original π§
$ workon
$ mkvirtualenv source
New python executable in source/bin/python
Installing setuptools.............................................
..................................................................
..................................................................
done.
(source)$ cpvirtualenv source dest
Making script /Users/dhellmann/Devel/virtualenvwrapper/tmp/dest/bin/easy_install relative
Making script /Users/dhellmann/Devel/virtualenvwrapper/tmp/dest/bin/easy_install-2.6 relative
Making script /Users/dhellmann/Devel/virtualenvwrapper/tmp/dest/bin/pip relative
Script /Users/dhellmann/Devel/virtualenvwrapper/tmp/dest/bin/postactivate cannot be made relative (it's not a normal script that starts with #!/Users/dhellmann/Devel/virtualenvwrapper/tmp/dest/bin/python)
Script /Users/dhellmann/Devel/virtualenvwrapper/tmp/dest/bin/postdeactivate cannot be made relative (it's not a normal script that starts with #!/Users/dhellmann/Devel/virtualenvwrapper/tmp/dest/bin/python)
Script /Users/dhellmann/Devel/virtualenvwrapper/tmp/dest/bin/preactivate cannot be made relative (it's not a normal script that starts with #!/Users/dhellmann/Devel/virtualenvwrapper/tmp/dest/bin/python)
Script /Users/dhellmann/Devel/virtualenvwrapper/tmp/dest/bin/predeactivate cannot be made relative (it's not a normal script that starts with #!/Users/dhellmann/Devel/virtualenvwrapper/tmp/dest/bin/python)
(dest)$ workon
dest
source
(dest)$
SEE ALSO π¦
scripts-precpvirtualenvscripts-postcpvirtualenvscripts-premkvirtualenvscripts-postmkvirtualenv
π allvirtualenv
Runs a command in all virtualenvs under WORKON_HOME. Full takeover energy π
Syntax:
allvirtualenv command with arguments
Each virtualenv gets activated (activation hooks get skipped), the working directory changes to the current virtualenv, and then your command runs. Commands can't change the current shell state, but they can change the virtualenv itself π§
$ allvirtualenv pip install -U pip
π― CONTROLLING THE ACTIVE ENVIRONMENT π―
π workon
Lists or switches your working virtual environments. This is the one you'll use the most, periodt π
Syntax:
workon [(-c|--cd)|(-n|--no-cd)] [environment_name|"."]
If you don't give an environment_name, the list of available environments gets printed to stdout π
If you use -c or --cd, the working directory switches to the project directory during the post-activate phase, no matter what VIRTUALENVWRAPPER_WORKON_CD is set to.
If you use -n or --no-cd, the working directory stays where it is during the post-activate phase, again regardless of VIRTUALENVWRAPPER_WORKON_CD.
If you pass "." as the environment name, the name gets derived from the base name of your current working directory. Huge thanks to Matias Saguir for contributing this one π«Ά
$ workon
$ mkvirtualenv env1
New python executable in env1/bin/python
Installing setuptools.............................................
..................................................................
..................................................................
done.
(env1)$ mkvirtualenv env2
New python executable in env2/bin/python
Installing setuptools.............................................
..................................................................
..................................................................
done.
(env2)$ workon
env1
env2
(env2)$ workon env1
(env1)$ echo $VIRTUAL_ENV
/Users/dhellmann/Devel/virtualenvwrapper/tmp/env1
(env1)$ workon env2
(env2)$ echo $VIRTUAL_ENV
/Users/dhellmann/Devel/virtualenvwrapper/tmp/env2
(env2)$
SEE ALSO π¦
scripts-predeactivatescripts-postdeactivatescripts-preactivatescripts-postactivatevariable-VIRTUALENVWRAPPER_WORKON_CD
π deactivate
Switches you out of a virtual environment and back to the system-installed version of Python π€οΈ
Syntax:
deactivate
NOTE: This command actually comes from virtualenv, but it gets wrapped so it can have before and after hooks, just like workon does for activate π
$ workon
$ echo $VIRTUAL_ENV
$ mkvirtualenv env1
New python executable in env1/bin/python
Installing setuptools.............................................
..................................................................
..................................................................
done.
(env1)$ echo $VIRTUAL_ENV
/Users/dhellmann/Devel/virtualenvwrapper/tmp/env1
(env1)$ deactivate
$ echo $VIRTUAL_ENV
$
SEE ALSO π¦
scripts-predeactivatescripts-postdeactivate
β¨ QUICKLY NAVIGATING TO A VIRTUALENV β¨
okay so there are two functions that give you shortcuts to hop straight into whatever virtualenv is currently active π¦
cdvirtualenv
This one changes your current working directory to $VIRTUAL_ENV, which is the top of your virtualenv πΈ You can also tack on an optional argument to the path, so you can dive right into a subdirectory in one move.
cdvirtualenv [subdir]
$ mkvirtualenv env1
New python executable in env1/bin/python
Installing setuptools.............................................
..................................................................
..................................................................
done.
(env1)$ echo $VIRTUAL_ENV
/Users/dhellmann/Devel/virtualenvwrapper/tmp/env1
(env1)$ cdvirtualenv
(env1)$ pwd
/Users/dhellmann/Devel/virtualenvwrapper/tmp/env1
(env1)$ cdvirtualenv bin
(env1)$ pwd
/Users/dhellmann/Devel/virtualenvwrapper/tmp/env1/bin
cdsitepackages
Okay this one is lowkey iconic π
The exact path to the site-packages directory depends on your Python version, so cdsitepackages is basically a shortcut for cdvirtualenv lib/python${pyvers}/site-packages so you don't have to remember it. You can also pass an optional argument to go even deeper into the site-packages directory.
cdsitepackages [subdir]
$ mkvirtualenv env1
New python executable in env1/bin/python
Installing setuptools.............................................
..................................................................
..................................................................
done.
(env1)$ echo $VIRTUAL_ENV
/Users/dhellmann/Devel/virtualenvwrapper/tmp/env1
(env1)$ cdsitepackages PyMOTW/bisect/
(env1)$ pwd
/Users/dhellmann/Devel/virtualenvwrapper/tmp/env1/lib/python2.6/site-packages/PyMOTW/bisect
lssitepackages
This one is giving "show me what's inside" π Calling lssitepackages lists the contents of the site-packages directory for whichever virtualenv is currently active.
lssitepackages
$ mkvirtualenv env1
New python executable in env1/bin/python
Installing setuptools.............................................
..................................................................
..................................................................
done.
(env1)$ $ workon env1
(env1)$ lssitepackages
setuptools-0.6.10-py2.6.egg pip-0.6.3-py2.6.egg
easy-install.pth setuptools.pth
β¨ PATH MANAGEMENT β¨
add2virtualenv
Main character energy for sharing packages π§ Adds the directories you specify to the Python path for the currently-active virtualenv. Sometimes you want to share installed packages that live outside the system site-packages directory and that you don't want installed in every single virtualenv. You could symlink the source into the environment's site-packages, but it's also easy to add extra directories to the PYTHONPATH by putting them in a .pth file inside site-packages using add2virtualenv.
add2virtualenv directory1 directory2 ...
Here's how to do it, bestie π
- Check out the source for a big project, such as Django.
- Run:
add2virtualenv path_to_source. - Run:
add2virtualenv. - A usage message and list of current "extra" paths gets printed.
- Use option
-dto remove the added path.
The directory names get added to a path file named _virtualenv_path_extensions.pth inside the site-packages directory for the environment.
Based on a contribution from James Bennett and Jannis Leidel π«Ά
toggleglobalsitepackages
This one is a switch and it's so satisfying π₯ It controls whether the active virtualenv can access the packages in the global Python site-packages directory.
toggleglobalsitepackages [-q]
It outputs the new state of the virtualenv. If you want zero output, use the -q switch to turn off all of it π€«
$ mkvirtualenv env1
New python executable in env1/bin/python
Installing setuptools.............................................
..................................................................
..................................................................
done.
(env1)$ toggleglobalsitepackages
Disabled global site-packages
(env1)$ toggleglobalsitepackages
Enabled global site-packages
(env1)$ toggleglobalsitepackages -q
(env1)$
β¨ PROJECT DIRECTORY MANAGEMENT β¨
SEE ALSO: project-management π
mkproject
Okay this is the one for starting fresh π mkproject creates a new virtualenv in the WORKON_HOME and a project directory in PROJECT_HOME.
mkproject [-f|--force] [-t template] [virtualenv_options] ENVNAME
-f,--forceβ creates the virtualenv even if the project directory already exists, so you can live a little π
The -t template option can be repeated to use several templates when making a new project. They get applied in the order you name them on the command line. Everything else gets passed straight to mkvirtualenv to create a virtual environment with the same name as the project π
$ mkproject myproj
New python executable in myproj/bin/python
Installing setuptools.............................................
..................................................................
..................................................................
done.
Creating /Users/dhellmann/Devel/myproj
(myproj)$ pwd
/Users/dhellmann/Devel/myproj
(myproj)$ echo $VIRTUAL_ENV
/Users/dhellmann/Envs/myproj
(myproj)$
SEE ALSO:
scripts-premkprojectscripts-postmkproject
setvirtualenvproject
This one is all about pairing things up π setvirtualenvproject binds an existing virtualenv to an existing project. The arguments are the full paths to the virtualenv and the project directory. Once the association is made, when workon activates the virtualenv, the project gets activated too.
setvirtualenvproject [virtualenv_path project_path]
$ mkproject myproj
New python executable in myproj/bin/python
Installing setuptools.............................................
..................................................................
..................................................................
done.
Creating /Users/dhellmann/Devel/myproj
(myproj)$ mkvirtualenv myproj_new_libs
New python executable in myproj/bin/python
Installing setuptools.............................................
..................................................................
..................................................................
done.
Creating /Users/dhellmann/Devel/myproj
(myproj_new_libs)$ setvirtualenvproject $VIRTUAL_ENV $(pwd)
If you don't give it any arguments, it assumes the current virtualenv and the current directory π¦
Any number of virtualenvs can point at the same project directory, which makes it super easy to hop between Python versions or other dependencies for testing β¨
cdproject
Change the current working directory to whatever is set as the project directory for the active virtualenv πΊοΈ
cdproject
β¨ MANAGING INSTALLED PACKAGES β¨
wipeenv
β οΈ bestie, this one is a big deal π wipeenv removes all of the installed third-party packages in the current virtualenv. Use it with intention!
wipeenv
β¨ OTHER COMMANDS β¨
virtualenvwrapper
When you need a little reminder, this one has your back π§Έ It prints a list of commands and their descriptions as basic help output.
virtualenvwrapper
β¨ COPYRIGHT β¨
2009-2019, Doug Hellmann π
That's the whole page, bestie π Version 4.8.4, dated Sep 03, 2019, and it's still giving πΈ Now go make a virtualenv and slay πβ¨
π¦ where this page comes from
- debian bookworm: virtualenvwrapper 4.8.4-4 Β· ISC
- debian trixie: virtualenvwrapper 4.8.4-4 Β· ISC
- ubuntu jammy: virtualenvwrapper 4.8.4-4 Β· ISC
- π girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms