Appendix
1
Virtual Environments
Python virtual environments enable you to set up a Python sandbox with its own set of packages separate from the system site-packages in which to work. There are many reasons to use virtual environments, such as if you have multiple services running with the same Python installation, but with different packages and package version requirements. In addition, you might find it handy to keep the dependent package requirements separate for every Python project you work on. Virtual environments let you do that.
The PyPI version of virtualenv works in most environments. As of Python 3.3, the venv virtual environment module is included as part of the standard library. However, some problems with venv have been reported on Ubuntu. Since virtualenv works with Python 3.6 (and as far back as Python 2.6) and on Ubuntu, we’ll use virtualenv in this quick overview.
Here’s how to set up a virtual environment in macOS and Linux:
| | $ pip install -U virtualenv |
| | $ virtualenv -p /path/to/a/python.exe /path/to/env_name |
| | $ source /path/to/env_name/bin/activate |
| | (env_name) $ |
| | ... do your work ... |
| | (env_name) $ deactivate |
You can also drive the process from Python:
| | $ python3.6 -m pip install -U virtualenv |
| | $ python3.6 -m virtualenv env_name |
| | $ source env_name/bin/activate |
| | (env_name) $ |
| | ... do your work ... |
| | (env_name) $ deactivate |
In Windows, there’s a change to the activate line:
| | C:/> pip install -U virtualenv |
| | C:/> virtualenv -p /path/to/a/python.exe /path/to/env_name |
| | C:/> /path/to/env_name/Scripts/activate.bat |
| | (env_name) C:/> |
| | ... do your work ... |
| | (env_name) C:/> deactivate |
You can do the same trick of driving everything from the Python executable on Windows as well.
In practice, setting up a virtual environment can be done in fewer steps. For example, I don’t often update virtualenv if I know I’ve updated it not too long ago. I also usually put the virtual environment directory, env_name, directly in my project’s top directory.
Therefore, the steps are usually just the following:
| | $ cd /path/to/my_proj |
| | $ virtualenv -p $(which python3.6) my_proj_venv |
| | $ source my_proj_venv/bin/activate |
| | (my_proj_venv) $ |
| | ... do your work ... |
| | (my_proj_venv) $ deactivate |
I’ve also seen two additional installation methods that are interesting and could work for you:
- Put the virtual environment in the project directory (as was done in the previous code), but name the env directory something consistent, such as venv or .venv. The benefit of this is that you can put venv or .venv in your global .gitignore file. The downside is that the environment name hint in the command prompt just tells you that you are using a virtual environment, but not which one.
- Put all virtual environments into a common directory, such as ~/venvs/. Now the environment names will be different, letting the command prompt be more useful. You also don’t need to worry about .gitignore, since it’s not in your project tree. Finally, this directory is one place to look if you forget all of the projects you’re working on.
Remember, a virtual environment is a directory with links back to the python.exe file and the pip.exe file of the site-wide Python version it’s using. But anything you install is installed in the virtual environment directory, and not in the global site-packages directory. When you’re done with a virtual environment, you can just delete the directory and it completely disappears.
I’ve covered the basics and common use case of virtualenv. However, virtualenv is a flexible tool with many options. Be sure to check out virtualenv --help. It may preemptively answer questions you may have about your specific situation. Also, the Python Packaging Authority docs on virtualenv[33] are worth reading if you still have questions.