Introduction
Most Python projects we develop will have dependencies: code written by other people that we install and use, so that we don’t have to re-write it ourselves.
For example, the requests library is a popular third-party dependency to make HTTP requests. The flask library is used to create web applications.
There are thousands upon thousands of libraries to do all kinds of things, and there are tens or hundreds of thousands of people working on those libraries.
We install and use libraries so that we don’t have to re-write all that code written by those people ourselves!
The libraries change over time, as new and better ways to do things are discovered and implemented.
As such, when we install a library for one of our projects, it will be a specific version. Months or years down the line, if try to install it again, it may well be a different version with different functionality.
Therefore, it’s possible that when we update a library, our code will no longer work because the way that we should use the library has changed.
Virtual environments exist so that we can separate the dependencies of one project from the dependencies of another project. That way, they can have different versions of the same library. That often happens when we start projects at different times.
What is a virtual environment?
There are two key parts to a virtual environment:
A specific version of Python, for example Python 3.9.
A folder of third-party libraries that you’ve installed.
Every virtual environment we create can be created with a different Python version. That lets us work on projects that use different Python versions very easily. Similarly, because each virtual environment has its own folder of third-party libraries, they can have different libraries or the same libraries in the same or different versions.
Virtual environments are kind of wrappers of python whenever we create a virtual environment, it creates a python environment having no third-party package installed even if your global python has a lot of packages installed. then you can activate this environment and install your desired packages and the scope of these packages will be limited to this specific virtual environment so you can install dependencies of 1 project in 1 virtual env and activate this specific environment whenever you wish to work on this project so that your all of dependencies are there and neither global nor other virtual env packages can interfere with it.
Creating a virtual environment
A common way people used to create virtual environments was with a python package known as virtualenv, but as of python version 3.3, parts of virtualenv actually got built into python under the module name venv. You can now create a virtual environment with the following command:
python3 -m venv venv
What’s going on here?
Well, python3 is your installation of python. If the version of python you installed is called python, python3.7or python3.9 or anything else, then use that;
-m venv is an argument that tells python to run the virtual environment module, venv;
and, finally, the last venv is the name of your virtual environment folder. Some people like to use another name (e.g. env or .env), however, this is completely up to you.
What this command should do is create a python virtual environment called venv at your current directory.
Note: if you use git, you will want to add venv/ to a new line of a file called .gitignore to make sure you don’t version control your virtual environment. If you forget this step, you can clog up your git repository with hundreds of additional version controlled files.
Once you have created your virtual environment, you won’t need to do this again.
Why Are Python Virtual Environments Important?
The importance of Python virtual environments becomes apparent when we have various Python projects on the same machine that depend on different versions of the same packages. For example, imagine working on two different data visualization projects that use the matplotlib package, one using version 2.2 and the other using version 3.5. This would lead to compatibility issues because Python cannot simultaneously use multiple versions of the same package. The other use case that magnifies the importance of using Python virtual environments is when you’re working on managed servers or production environments where you can’t modify the system-wide packages because of specific requirements.
Python virtual environments create isolated contexts to keep dependencies required by different projects separate so they don’t interfere with other projects or system-wide packages. Basically, setting up virtual environments is the best way to isolate different Python projects, especially if these projects have different and conflicting dependencies. As a piece of advice for new Python programmers, always set up a separate virtual environment for each Python project, and install all the required dependencies inside it — never install packages globally.
Activate the virtual environment
Before you can use this virtual environment, you need to explicitly activate it. Activation makes the virtual environment the default Python interpreter for the duration of a shell session.
You’ll need to use different syntax for activating the virtual environment depending on which operating system and command shell you’re using.
On Unix or MacOS, using the bash shell: source /path/to/venv/bin/activate
On Unix or MacOS, using the csh shell: source /path/to/venv/bin/activate.csh
On Unix or MacOS, using the fish shell: source /path/to/venv/bin/activate.fish
On Windows using the Command Prompt: path\to\venv\Scripts\activate.bat
On Windows using PowerShell: path\to\venv\Scripts\Activate.ps1
Note that the activated environment only works for the context it was activated in. For instance, if you launch two instances of PowerShell, A and B, and you only activate the virtual environment in instance A, that environment will only apply to A. It wouldn’t apply anywhere else.
Many Python IDEs automatically detect and activate a virtual environment if one is found in the current project directory. Microsoft Visual Studio Code, for instance, can do this when the Python extension is enabled. Opening a terminal inside Visual Studio Code will automatically activate the selected virtual environment.
Conclusion
When creating virtual environments, always try to use venv as the environment name since it is a global convention that is easily available in ignore files like .gitignore.
It is generally a good practice to work with virtual environments as they save you hours of debugging common errors like the No module error. They also enable easy collaboration between developers.