This site is supported by our readers. We may earn a commission, at no cost to you, if you purchase through links.
You install a package for one project, and another project quietly breaks. The cause is almost always the same: two apps demanding different versions of the same library, fighting over a single shared Python install.
Creating a python environment solves this by giving each project its own sealed workspace. Packages stay separate, versions never collide, and you can delete the whole thing without touching your system.
It also gives you full control over what your code depends on. Once you see how little it takes, you’ll never install a package globally again. Let’s start by checking what’s already on your machine.
Table Of Contents
- Key Takeaways
- Why Python Virtual Environments Matter
- Check Python and Venv Availability
- Create a Python Virtual Environment
- Activate Your Python Environment
- Install Packages and Save Project Dependencies
- Deactivate and Remove Your Python Environment
- Frequently Asked Questions (FAQs)
- Can virtual environments use different Python versions?
- Should I commit my virtual environment to Git?
- Can I move a virtual environment to another folder?
- Are virtual environments compatible with Jupyter Notebooks?
- What happens to environments during Python upgrades?
- What is the difference between venv and virtualenv?
- Conclusion
Key Takeaways
- A virtual environment gives each project its own private set of packages, so you can run Django 3 in one project and Django 5 in another without anything breaking.
- You’ll need Python 3.3 or newer, since venv ships with it, and you create an environment with
python -m venv.venvbefore switching it on with the activation command for your system. - Once the environment is active, pip installs packages only inside it, and
pip freeze > requirements.txtlets a teammate rebuild your exact setup withpip install -r requirements.txt. - Keep the environment out of Git, don’t move it after you create it, and when you’re done, just delete the folder or recreate it from requirements.txt after a major Python upgrade.
Why Python Virtual Environments Matter
Every Python project you build leans on outside packages, and those packages rarely agree on versions. Imagine one project needs Django 3 while another needs Django 5. Install both globally and one of them breaks.
A virtual environment solves this by giving each project its own private space. It’s like having a separate toolbox for every single job. This dependency isolation keeps your system Python clean and protects you from unpredictable behavior.
Give every project its own toolbox, and your system stays clean while your code stops fighting itself
You also gain reproducibility. Once your project dependencies live inside the environment, you can list them in a file and share it. Teammates can then rebuild your setup exactly, so "it works on my machine" stops being an excuse. A requirements.txt file records precise package versions, which lets anyone recreate the same development environment on a different system.
Experiments are safe: delete the environment and move on.
Check Python and Venv Availability
Before you build anything, make sure your machine has what it needs. We’ll check two things: Python itself and the venv module.
First, open your terminal or Command Prompt and run **python --version**. If you get an error or see Python 2, try python3 --version instead. On Windows, py -3 --version does the same job.
You want Python 3.3 or newer, because the venv module ships with it. Confirm it’s there by running **python3 -m venv --help**. If usage text appears, you’re ready.
Some Linux distributions package venv separately, so the command may fail. If that happens, add it with your package manager, for example **sudo apt install python3-venv**. This keeps you away from a system-wide installation of project libraries.
Create a Python Virtual Environment
Now that your tools are in place, let’s build the environment. Start by moving into your project folder with **cd**.
Next, run **python -m **venv**.venv**. The last part is just a folder name, and .venv is a common choice. If you want a specific version, use that interpreter instead, such as python3.12 -m venv.venv.
Think of it like setting up a fresh workbench. Your project gets its own tools, and nothing spills into other projects.
After a moment, you’ll see a new .venv folder. Inside, **pyvenv.cfg** records which interpreter you used. Since the environment points back to that Python, don’t move or uninstall it. Add .venv to your .**gitignore** too, because these files belong to your machine alone.
Activate Your Python Environment
Your new environment exists, but it won’t do anything until you switch it on. Activation tells your shell to use this project’s Python and pip instead of the system ones. The command depends on your operating system and shell, so we’ll cover each option below.
Windows Command Prompt and PowerShell
Worried the activation step is tricky on a Windows system? It isn’t. Once you’ve run python -m venv venv, you only need three moves:
- Open Command Prompt and run venvScriptsactivate.bat.
- In PowerShell, run .venvScriptsActivate.ps1 instead.
- Look for (venv) at the start of your prompt.
That prefix confirms you’re working inside your isolated environment. Now you’re in control.
MacOS and Linux Shells
A single command switches your shell into the environment. In bash or zsh, run source myenv/bin/activate, swapping in your own folder name. This adjusts your PATH and sets the VIRTUAL_ENV variable, so python and pip now point inside the project.
Using fish? Run source myenv/bin/activate.fish instead. Your prompt will show (myenv) when it works.
Install Packages and Save Project Dependencies
Your environment is active, so it’s time to put it to work. We’ll cover two things next: how to install packages with pip and how to save them so anyone can rebuild your setup. Let’s take them one at a time.
Install Isolated Packages With Pip
With your environment active, pip installs everything inside it. Here’s how to keep control of package installation:
- Run **pip install** requests for a normal install.
- Add –**no-deps** to skip dependencies.
- Pair –no-deps with a requirements file for strict dependency management.
- Use –**no-build-isolation** to handle build tools yourself.
Each flag gives you more control over what lands in your isolated environment.
Reproduce Environments With Requirements.txt
Say your teammate Maria clones your project and hits an error because her version of requests is newer than yours. A requirements.txt file prevents that.
With your environment active, run pip freeze > requirements.txt. Then Maria creates a fresh venv and runs pip install -r requirements.txt. She gets your exact package versions, so the code behaves the same for both of you.
Deactivate and Remove Your Python Environment
Say you’ve finished a small weather app and want to start a fresh project tomorrow. Your prompt still shows (venv), so you’re still inside the old setup. Let’s close it out.
First, run deactivate to deactivate your virtual environment. The (venv) prefix vanishes, and you’re back on the system interpreter. Nothing is lost, since you can reactivate it later.
Next, save your packages with pip freeze > requirements.txt if you might need them again. Then delete the virtual environment folder when you’re done with it. On Windows, use rmdir /s /q venv in Command Prompt. On macOS and Linux, use rm -rf venv.
Think of the folder as a toolbox. Tossing it is safe, and regular environment cleanup frees space.
Frequently Asked Questions (FAQs)
Can virtual environments use different Python versions?
Yes, they can. Each python virtual environment uses the interpreter that created it, so you choose the version by running that interpreter’s command, like python12 -m venv.venv. Your other projects keep their own versions.
Should I commit my virtual environment to Git?
Committing your venv is like mailing someone your whole kitchen when they only need the recipe. Skip it.
Add the folder to your Git ignore file, and commit requirements.txt instead. That keeps environment reproducibility simple.
Can I move a virtual environment to another folder?
Moving a venv is a disaster waiting to happen. Its scripts remember the old location, so activation and commands break. Don’t move it. Create a fresh one in the new folder, then reinstall from requirements.txt.
Are virtual environments compatible with Jupyter Notebooks?
Think of a virtual environment as a locked toolbox, and the kernel as the key that opens it. Yes, they work together. Register the environment as a kernel with ipykernel, then select it in your notebook.
What happens to environments during Python upgrades?
When Python upgrades, your environments don’t update with it. They keep the old version recorded in pyvenv.cfg, so you get a hybrid setup. Minor upgrades usually work. Major upgrades break things, so recreate the environment and reinstall.
What is the difference between venv and virtualenv?
The main difference is where each tool comes from. venv ships with Python 3 and later, so you’ve got it already. virtualenv is a third-party package you install yourself, but it can use other interpreters.
Conclusion
You create the folder, you activate the workspace, and you install only what the project needs. That’s the whole routine. Each step takes seconds, and together they keep your projects clean, predictable, and separate.
Creating a python environment is a small habit with a big payoff. Your dependencies live in one place, your requirements.txt rebuilds them anywhere, and your system stays untouched. Total control is now a few commands away. Start your next project clean.
