Python Tutorial: VENV (Windows) - How to Use Virtual Environments with the Built-In venv Module
Based on Corey Schafer's video on YouTube. If you like this content, support the original creators by watching, liking and subscribing to their content.
Use `python -m venv <env_name>` to create isolated environments per project and avoid dependency version conflicts.
Briefing
Virtual environments solve a practical dependency problem: they let each project install its own Python packages without risking version conflicts in other projects. A common failure mode is upgrading a framework like Django globally—older projects can break when they still need Django 1.x while new work expects Django 2.x. By isolating packages per project, virtual environments keep dependencies from bleeding across codebases.
On Windows, the built-in `venv` module provides this isolation without any extra installation because it ships with Python (requires Python 3.3+; the walkthrough uses Python 3.7). The process starts by checking the system’s installed packages with `pip list`, then creating an environment using `python -m venv <env_name>`. The environment is created in the current directory, producing a folder (for example, `projectenv` on the desktop). Activation is done via the environment’s script: ` <env_name>\Scripts\activate.bat`. Once active, the command prompt shows the environment name, and `where python` confirms that the Python executable now points inside the virtual environment.
Inside the activated environment, `pip list` typically shows only `pip` and `setuptools` initially. Installing packages with `pip install <package>` places them only in that environment. The tutorial demonstrates installing `requests` and `pyz`, then verifying the result with another `pip list`. For reproducibility, dependencies can be exported using `pip freeze`, which outputs package versions in a format suitable for a `requirements.txt` file. Creating that file lets someone else recreate the same environment by activating the environment and running `pip install -r requirements.txt`.
Deactivation is handled with `deactivate`. If the environment is no longer needed, it can be removed by deleting the environment directory; the walkthrough uses command-line deletion (`rmdir /s`) and notes that dragging the folder to the trash works too. A best-practice convention is to place the virtual environment inside the project folder (often named `venv`) while keeping project source files outside the environment directory—so the environment can be thrown away and rebuilt safely. It also recommends not committing the virtual environment to source control; instead, commit `requirements.txt` so others can recreate dependencies.
Finally, `venv` can be configured to include access to globally installed packages using the `--system-site-packages` option. Creating an environment with `python -m venv venv --system-site-packages` makes global packages available inside the environment, while newly installed packages still remain isolated. The walkthrough verifies this by installing a package like `SQLAlchemy` inside the environment and then using `pip list --local` to show only environment-installed packages, confirming that the global Python installation remains unchanged.
Cornell Notes
Virtual environments prevent dependency conflicts by isolating installed packages per project. On Windows, the built-in `venv` module creates an environment with `python -m venv <env_name>` and activates it with `<env_name>\Scripts\activate.bat`, after which `pip` installs packages only into that environment. Dependencies can be shared and reproduced using `pip freeze` to generate a `requirements.txt` file, then installing with `pip install -r requirements.txt`. Environments can be deactivated with `deactivate` and deleted by removing the environment directory. For cases where global packages are needed, `venv` supports `--system-site-packages`, and `pip list --local` helps distinguish environment-installed packages from inherited system packages.
Why does isolating dependencies per project matter, and what problem does `venv` address?
What exact commands create and activate a virtual environment using the built-in `venv` module on Windows?
How can dependencies be exported from one environment and recreated in another?
What’s the recommended workflow for where to store the virtual environment and how to treat it in source control?
How does `--system-site-packages` change `venv` behavior, and how can you verify what’s local vs inherited?
Review Questions
- What steps would you follow to create a new `venv`, install packages, and confirm that `pip` is targeting the environment rather than the global Python?
- How would you use `pip freeze` and `pip install -r requirements.txt` to reproduce an environment on another machine?
- When would you choose `--system-site-packages`, and what command helps you distinguish environment-installed packages from system-inherited ones?
Key Points
- 1
Use `python -m venv <env_name>` to create isolated environments per project and avoid dependency version conflicts.
- 2
Activate on Windows with `<env_name>\Scripts\activate.bat`, then confirm isolation using `where python` and `pip list`.
- 3
Install packages with `pip install <package>` only after activation so they land in the correct environment.
- 4
Export reproducible dependencies with `pip freeze` into `requirements.txt`, then recreate them using `pip install -r requirements.txt`.
- 5
Deactivate with `deactivate`, and delete an environment by removing its directory (e.g., `rmdir /s`).
- 6
Keep source code outside the virtual environment folder and don’t commit the environment to source control—commit `requirements.txt` instead.
- 7
If needed, create environments with `--system-site-packages` to access global packages, and use `pip list --local` to see only environment-installed packages.