Python venv Cheatsheet
some usefull venv commands
Venv is a virtual environment management commandline tool. A much more simple one, comparing to Anaconda. Here are some usefull venv commands.
Python venv Cheat Sheet
Create a Virtual Environment
-
Standard command (Python 3.3+):
python -m venv venv
This creates a virtual environment named
venv
in your current directory. -
With a specific Python version (if installed):
python3.10 -m venv venv
or using
virtualenv
:virtualenv -p /usr/local/bin/python3.10 venv
(Requires
virtualenv
package).
Activate the Virtual Environment
- On Windows:
.\venv\Scripts\activate
- On macOS/Linux:
The shell prompt should now show the environment name.source venv/bin/activate
Deactivate the Virtual Environment
- All platforms:
This returns you to your system Python.deactivate
Installing Packages
- With pip:
Example:pip install
pip install numpy pandas
- Upgrade pip (recommended):
python -m pip install --upgrade pip
Freeze and Export Requirements
- Save current environment packages:
pip freeze > requirements.txt
- Install from requirements file:
Ensure your virtual environment is activated before running these commands.pip install -r requirements.txt
Remove a Virtual Environment
deactivate
rm -rf <env path>
Common Pitfalls When Managing Python Virtual Environments
Forgetting to Activate the Virtual Environment
- A frequent mistake is running commands without activating the intended virtual environment, leading to package installations in the global environment or the wrong venv. This can cause dependency conflicts and unpredictable behavior.
Not Pinning Package Versions
- Using loose version specifiers (like
>=
instead of==
) inrequirements.txt
undermines reproducibility. Exact version pinning ensures that everyone working on the project uses the same package versions, preventing unexpected issues during deployment or collaboration.
Mixing Global and Virtual Environments
- Accidentally installing packages globally or mixing global and virtual environments can create conflicts, especially if different projects require incompatible package versions. Always ensure you are operating within the correct environment.
Committing Virtual Environments to Version Control
- Including the virtual environment directory (e.g.,
venv/
) in version control bloats repositories and is unnecessary. Always add venv directories to.gitignore
to keep your repository clean.
Neglecting to Separate Development and Production Dependencies
- Failing to distinguish between development and production dependencies can result in bloated or insecure deployments. Use separate requirements files or configuration sections for each.
Lack of Documentation and Automation
- Not documenting environment setup steps or failing to automate the process (with scripts or Makefiles) makes onboarding new contributors and reproducing environments more difficult.
Not Regularly Cleaning Up Old Environments
- Over time, unused virtual environments can accumulate, wasting disk space and causing confusion. Regularly remove obsolete venvs to maintain a tidy workspace.
Ignoring System Python and Package Manager Boundaries
- Modifying the system Python or mixing system package managers with pip can break system tools and introduce hard-to-diagnose issues. Always use venvs for project dependencies and avoid interfering with system-managed packages.
Summary Table
Pitfall | Impact |
---|---|
Forgetting to activate venv | Installs packages in wrong environment |
Not pinning package versions | Unpredictable builds, hard-to-reproduce bugs |
Mixing global and virtual environments | Dependency/version conflicts |
Committing venv directories to version control | Bloated, messy repositories |
Not separating dev and prod dependencies | Bloated/insecure production environments |
Lack of documentation/automation | Hard onboarding, inconsistent setups |
Not cleaning up old environments | Disk space waste, confusion |
Modifying system Python or packages | System instability, broken tools |
Following best practices-such as always activating your venv, pinning dependencies, separating environments, and maintaining clear documentation-can help you avoid these common pitfalls.
Key Differences Between Conda and Virtual Environments for Reproducibility
Feature | Conda Environments | Python Virtual Environments (venv/virtualenv) |
---|---|---|
Scope of Management | Manages Python packages and non-Python dependencies (e.g., system libraries, compilers) | Manages only Python packages via pip |
Python Version Control | Can specify and install any Python version per environment | Uses the system-installed Python version |
Cross-Platform Consistency | More consistent across different OS (Windows, macOS, Linux) due to managing all dependencies | Relies on system libraries, which may differ by OS |
Package Sources | Uses Conda repositories (precompiled binaries, scientific stack) | Uses PyPI (pip) for Python packages |
Reproducibility | Higher for complex, scientific, or mixed-language projects; can export full environment (conda env export ) |
Good for pure-Python projects; may lack reproducibility if system dependencies are involved |
Non-Python Dependencies | Can install and manage (e.g., OpenBLAS, libpng) | Cannot manage; must be installed separately |
Environment Export/Import | conda env export / conda env create for full reproducibility |
pip freeze > requirements.txt / pip install -r requirements.txt (Python packages only) |
Performance | Faster and more reliable for large scientific packages (e.g., numpy, pandas) | May require compiling from source, especially on Windows |
Complexity | Slightly higher setup and management overhead | Lightweight, simpler for basic Python projects |
Summary of Key Points
-
Conda environments are ideal for reproducibility in projects requiring both Python and non-Python dependencies, or when exact replication across platforms is critical. Conda manages the entire stack-including Python itself, libraries, and even compilers-making it easier to share and reproduce complex environments, especially in data science and research contexts.
-
Python virtual environments (
venv
/virtualenv
) are lightweight and excellent for isolating Python dependencies in pure-Python projects. However, they do not manage system-level or non-Python dependencies, so reproducibility may be compromised if your project relies on external libraries or specific system configurations. -
Exporting and sharing environments: Conda allows you to export a full environment specification (
conda env export
), including all dependencies and their versions, which can be recreated exactly elsewhere. With virtual environments,pip freeze
only captures Python packages, not system dependencies or the Python interpreter version. -
Conclusion
Use Conda for maximum reproducibility in scientific, cross-platform, or complex projects. Use Python virtual environments for lightweight, pure-Python projects where system dependencies are not a concern.