Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
Understanding Virtual Environments for Python
Several times now, I've seen advice in tutorials, setup/install instructions for Python-based projects, etc. to use a virtual environment to keep things organized and make it simpler to manage the code.
It sounds like this means having yet another installation of Python on my computer. Does it really work that way? Why would I want to do this, when I'm already having headaches keeping track of multiple separate versions of Python?
What does creating and "activating" a virtual environment do, and how can I benefit from this?
1 answer
The following users marked this post as Works for me:
| User | Comment | Date |
|---|---|---|
| Karl Knechtel | (no comment) | Jun 14, 2024 at 12:41 |
Why
The most important ideas behind virtual environments are:
-
Since there is a separate
site-packages, you can isolate the dependencies of your project. This is especially important for testing and development, since you can more easily verify what your project's dependencies actually are. That is, you'll be able to package the project properly, and enable Pip to install the right dependencies when other people use your code. Isolating dependencies like this also allows you to use a different version of a given library, rather than the one installed in the base environment. -
By default, virtual environments will "bootstrap" Pip into them, even if the "base" environment doesn't have Pip. This is especially important on certain Linux installations (such as Debian-based ones), since it allows you to keep using the system package manager for the system Python (and not have to install Pip via the system package manager and risk damaging your system), while still being able to use Pip in a separate environment that can't interfere with your operating system's scripts. (The environment also contains a copy or symlink of the Pip executable wrapper.)
-
When you "activate" the environment,
pythonautomatically means the environment's python andpipmeans the environment's Pip, which installs to the environment'ssite-packagesby default. The system is automatically configured to make sure that everything is lined up, so you won't accidentally install third-party libraries for the wrong environment. (Newer versions of Pip are aware that a virtual environment is active, and will complain if you try to use the--useroption to bypass the virtual environment'ssite-packages.)
See PEP 405 for technical details of how the virtual environment ensures everything is properly set up.
What
A virtual environment for Python is basically a folder that contains
-
a copy of, or symlink to, the Python executable that was used to create it
-
possibly copies of, or symlinks to, standard library modules
-
a separate
site-packagessub-folder to store third-party libraries that are specific to this environment -
an "activation" script
-
some configuration data
Since Python 3.3, virtual environments can be created using the venv standard library module. This functionality was not backported to Python 2.7. Users of older Python needed to use a third-party tool such as virtualenv. (virtualenv is still maintained, and offers additional features that are missing from venv - but which most people won't need.)
How
Creating the environment
(Linux/Mac)
user@machine:~$ python -m venv .venv
(Windows)
C:\Users\user\> py -m venv .venv
Here, .venv is any arbitrary name that will be used for the virtual environment's folder. (A leading dot on the filename is often desirable so that the operating system will treat the folder as "hidden".) The python or py part of the command can be replaced with whatever makes sure that the right Python installation is used. The virtual environment will copy or symlink whichever Python interpreter was used to run venv.
To see a full list of options for venv, use the --help flag instead of giving a folder name: e.g. python -m venv --help. You can also consult the documentation linked above.
Activating a virtual environment
Simply run the activation script provided by the virtual environment:
(Linux/Mac)
user@machine:~$ source .venv/bin/activate
(Windows, CMD)
C:\Users\user\> .venv\Scripts\activate.bat
(Windows, PowerShell)
PS C:\Users\user\> .venv\Scripts\activate.ps1
Deactivating a virtual environment
Use the deactivate command. It works the same way (although the implementation may differ) regardless of your operating system, and there are no command-line options for it. It simply undoes the changes that the activation script made.
It's basically never necessary to activate a virtual environment. All that activation does is change some environment variables so that the PATH refers to the virtual environment and the prompt reminds you about this, and set up deactivation. If you want to use the virtual environment without activating it, simply give the path to its Python (or Pip) explicitly. (If your virtual environment uses symlinks, use the path to the symlink, not the path that it's linked to.)
Deleting a virtual environment
Simply delete the folder, the same way you would delete any other folder.
Moving a virtual environment
Virtual environments cannot reliably be relocated. If you try to move the folder around, the environment may simply break in mysterious ways.
The simplest safe approach is to clone the environment. Use Pip to record the contents of the old environment; then create a new environment, install the recorded dependencies, and finally remove the old environment. For example, "renaming" .venv1 to .venv2:
(Linux/Mac)
user@machine:~$ source .venv1/bin/activate
(.venv1) user@machine:~$ pip freeze > requirements.txt
(.venv1) user@machine:~$ deactivate
user@machine:~$ python -m venv .venv2
user@machine:~$ source .venv2/bin/activate
(.venv2) user@machine:~$ pip install -r requirements.txt
(.venv2) user@machine:~$ rm -rf .venv1
(Windows)
C:\Users\user\> .venv1\Scripts\activate.bat
(.venv1) C:\Users\user\> pip freeze > requirements.txt
(.venv1) C:\Users\user\> deactivate
C:\Users\user\> py -m venv .venv2
C:\Users\user\> .venv2\Scripts\activate.bat
(.venv2) C:\Users\user\> pip install -r requirements.txt
(.venv2) C:\Users\user\> rd /s /q .venv1
0 comment threads
0 comment threads