Creating a Python Virtual Environment
Understanding Dependencies in Python
In real-world Python projects, it's common to rely on multiple dependencies. Dependencies refer to external modules, packages, or libraries that you import to your project to perform essential functionalities. These are reusable codes developed by other programmers.
To understand dependencies, it’s important to break down related concepts: modules, packages, and libraries. A module is a collection of codes saved in a file with the extension .py
. A package is a collection of modules organized in directories, usually with an __init__.py
file. A library is a collection of packages and modules with a common purpose. However, programmers often use the terms library and package interchangeably.
For example, an electronic medical record might rely on the requests module to handle HTTP requests, the Django package as its web application framework, and the pandas library for data analysis and manipulation. Each of these is a dependency because the project cannot function as intended without them.
The Problem: Conflicting Dependencies in Multiple Python Projects
Managing dependencies for a single Python project is relatively straightforward. However, things become more complex when you're working on multiple projects. Imagine working on two separate Python projects: one is a legacy application that relies on Python 3.7 and uses an older version of a specific package, while the other is a newer project built with Python 3.10, requiring the latest version of that same package.
In such cases, conflicts arise, as both projects need different versions of Python and the package to function correctly. Upgrading the package for the newer project could break the legacy one. Similarly, trying to run the legacy project with Python 3.10 might cause compatibility issues with the code or other dependencies.
The Solution: Managing Dependencies Through Virtual Environment
The solution to managing conflicting dependencies between multiple Python projects is to create a virtual environment for each project. A virtual environment allows you to isolate each project so that they can run independently with their own version of Python and required packages. This ensures that the dependencies for one project won’t interfere with the dependencies of another.
Ways to Create a Virtual Environment
There are several options available for creating virtual environments in Python, each with its own set of features and benefits. Some popular choices include:
- venv: A built-in module available in Python 3.3 and later, making it convenient and easy to use without needing additional installations.
- Virtualenv: A more flexible option that works with older Python versions and offers advanced features for managing environments.
- Conda: A powerful package manager and environment manager, especially popular in the data science community due to its ability to manage both Python and non-Python dependencies.
- Poetry: A newer tool that simplifies dependency management and packaging, combining virtual environments and dependency resolution into one tool.
- pipenv: An all-in-one tool that integrates pip and virtualenv to manage dependencies and virtual environments.
- virtualenvwrapper/virtualenvwrapper-win: A set of extensions to make virtualenv easier to manage, especially when working with multiple environments.
For this tutorial, we will use venv because it is built into Python (starting with version 3.3), making it the simplest and most accessible option.
Creating a Virtual Environment
Best Practice: Always create a separate virtual environment for each Python project.
In my tutorial, Structuring Python Project Directories, we set up a dedicated folder to store the virtual environment. Let us use the Gen EMR project as an example. Open up your terminal and navigate to the directory below:
1 2 3 |
|
Enter the following command in your terminal:
1 |
|
The previous command will generate the necessary files for the virtual environment in the current directory. If you haven't yet created a directory for your virtual environment, you can replace the .
with your preferred directory name. Keep in mind that this directory name will also become the name of your virtual environment. For instance, in our example, we use gen_emr_venv
.
The end result will be similar to this:
1 2 3 4 5 6 7 |
|
Activating the Virtual Environment
Best Practice: Always activate your virtual environment before working on your Python Project.
Navigate to your root directory:
1 2 3 |
|
Enter the following command in your terminal:
1 |
|
The result will display the name of the activated virtual environment enclosed in parentheses in your terminal.
1 |
|
When you activate a virtual environment, your project operates in its own isolated bubble, meaning any packages you install or update will only affect that specific environment. Any dependencies you install will go into the site-packages
directory under the Lib/
.
Deactivating the Virtual Environment
You can deactivate the virtual environment by typing:
1 |
|
When a user deactivates the virtual environment, the terminal exits the isolated environment and returns to the system’s global Python environment. The virtual environment's name will disappear from the terminal prompt, indicating that you're no longer working within that specific environment.
1 |
|
If the user installs a package after deactivating the virtual environment, the package will be installed globally, affecting the system-wide Python environment. This can lead to conflicts between dependencies of different projects, as any package installed globally will be available to all Python projects on the system.