Python venv

Python development often involves working on multiple projects, each potentially requiring different versions of libraries or even Python itself. Without proper isolation, managing these dependencies can quickly turn into a tangled mess of conflicting packages. This is where Python virtual environments come into play, offering a clean, isolated space for each project. The built-in venv module is the standard and recommended way to achieve this.

What is a Virtual Environment?

A virtual environment is a self-contained directory that holds a specific Python interpreter and its own set of installed packages. It acts as an isolated sandbox for your project, preventing package conflicts between different projects on your system. When you install a package within an active virtual environment, it only gets installed in that environment, leaving your global Python installation untouched.

Why Use venv?

1. Dependency Isolation: Each project can have its own versions of libraries without affecting others. Project A might need requests==2.20.0 while Project B needs requests==2.28.0. A virtual environment allows this without conflict.
2. Clean Global Environment: Your system's global Python installation remains pristine, free from project-specific packages.
3. Reproducibility: You can easily share your project's requirements.txt file, allowing other developers (or your future self) to recreate the exact environment needed for the project to run.
4. Testing: Experimenting with different package versions is safer and easier.

Creating a Virtual Environment

The venv module is included with Python 3.3 and later, so you don't need to install anything extra.

To create a virtual environment, navigate to your project's root directory in your terminal and run:

• python3: This specifies which Python interpreter to use. If you have multiple Python versions installed (e.g., Python 3.8 and Python 3.10), use python3.8 -m venv myproject_env or python3.10 -m venv myproject_env to select a specific one.
• myproject_env: This is the name of the directory where your virtual environment will be created. It's a common practice to name it .venv, venv, or env.

After running this command, a new directory named myproject_env (or whatever you named it) will be created in your project folder. Inside, you'll find bin (or Scripts on Windows), lib, include, and a pyvenv.cfg file.

Activating the Virtual Environment

Once created, you need to "activate" the environment to start using it. This modifies your shell's PATH variable so that python and pip commands point to the executables within your virtual environment, not your global ones.

• On macOS/Linux:

• On Windows (Command Prompt):

• On Windows (PowerShell):

After activation, your terminal prompt will usually change to indicate the active environment (e.g., (myproject_env) your_username@your_machine:~/my_project_folder$).

Installing Packages in the Environment

With the environment activated, you can now install packages using pip just as you normally would. These packages will be installed *only* in your myproject_env environment.


To see what packages are installed in your active environment:


Deactivating the Virtual Environment

When you're done working on a project or need to switch to another project with a different environment, you can deactivate the current one:


Your terminal prompt will return to its normal state, and python and pip will once again refer to your global installations.

Deleting a Virtual Environment

To remove a virtual environment, simply delete its directory. There's no special command needed.


Best Practices

1. Name Convention: Stick to venv or .venv for your virtual environment directory name. Many IDEs (like VS Code, PyCharm) automatically detect and configure themselves to use a venv directory.
2. requirements.txt: After installing all necessary packages for your project, generate a requirements.txt file. This allows others (or yourself later) to easily replicate the environment.
To install packages from this file:
3. .gitignore: Always add your virtual environment directory (e.g., venv/ or .venv/) to your project's .gitignore file. You don't commit virtual environments to version control; they should be recreated from requirements.txt.

By consistently using venv for your Python projects, you'll maintain a clean, organized, and reproducible development workflow, saving you from many potential dependency headaches.