With the theory established, we must move on to the actual execution. There are three simple phases to using a virtual environment on Linux: Creation, Activation, and Verification.
The tool used to build this environment is the venv module, which is part of the standard Python installation. However, on some bare-bones Linux distributions (like standard Debian or Ubuntu minimal installs), you might need to install the python3-venv package first using your system package manager:
$ sudo apt update
$ sudo apt install python3-venv
Once that tool is confirmed, we go into our project directory and create the sandbox. The syntax is: python3 -m venv <directory_name>. The universal convention is to simply name the directory venv, keeping it self-descriptive and hidden by default from casual file listings.
Navigate to your project folder:
$ cd ~/my_python_project
Create the environment directory named 'venv'. It doesn't have to be named 'venv', name it what you like, but 'venv' makes it clear that this is a virtual environment:
$ python3 -m venv venv
Under the Hood:
If you explore this new venv directory, you will see it contains its own copies of the Python binary (interpreter) and the pip package manager. You have successfully duplicated a miniature version of the entire Python infrastructure inside your project folder.
Creating the environment isn't enough. You must actively enter it. Your shell (terminal) needs to know that when you run python or pip from now on, it should use the binaries located inside your sandbox, not the system-wide ones. This is accomplished by "sourcing" the activation script.
Inside your project folder:
$ source venv/bin/activate
Visual Change:
Look at your command prompt. It will change, typically showing the name of your virtual environment in parentheses at the start:
(venv) user@linux:~/my_python_project$
This visual confirmation is your first, immediate sign that your shell environment has successfully switched.
As professional developers, we verify. The system just told us the environment is active, but we can double-check exactly which python interpreter the shell is using. The which command is our verification tool.
While inside the activated venv folder:
$ which python3
The Output:
Instead of showing /usr/bin/python3 (the global system path) it should now show something like:
/home/user/my_python_project/venv/bin/python3
We have now verified that your project sandbox is completely isolated. Any libraries you install using pip while this environment is active will only exist within this specific project folder.
Leaving the Sandbox (Deactivation)
When you are finished working on this project, you want to return your terminal to its default state. This step is crucial before jumping into a different project that might have conflicting requirements. Simply type:
$ deactivate
Your prompt will return to normal, and running which python3 will once again point to the global system installation.
You might be wondering: "If I have to do all that work in the CLI, does VS Code just ignore it?"
Actually, the opposite is true. VS Code is highly "environment-aware." Because it relies on the Python extension for its heavy lifting, it is designed to bridge the gap between your manual CLI work and the editor's automated features. Once you've created and activated your virtual environment, VS Code makes the transition nearly seamless.
When you open a project folder that contains a venv directory, the Python extension typically scans the folder immediately. It recognizes that a virtual environment exists and will usually prompt you in the bottom-right corner to select that specific interpreter. If it doesn't do it automatically, you can trigger it manually with a simple command sequence.
Manual Interpreter Selection
If VS Code doesn't "see" your environment, or if you need to switch to a different one, you don't need to guess where the files are:
Open the Command Palette (shortcut: Ctrl+Shift+P).
Type "Python: Select Interpreter" and hit Enter.
You will see a list of available Python environments on your system. Look for the one that matches your project path: ~/my_python_project/venv/bin/python3.
Once selected, VS Code updates its internal settings (.vscode/settings.json) so that any tool you run—like the debugger, the linter, or the "Run" button—uses that specific virtual environment.
This is the most critical feature for developers. When you open a new integrated terminal in VS Code (Ctrl+ ) inside a folder with an active virtual environment, VS Code will automatically execute the activation command for you.
You will see the (venv) prefix appear in your terminal prompt without you having to type source venv/bin/activate.
Pro Tip: If you ever switch environments or find that your VS Code terminal isn't "seeing" your new packages, simply kill the current terminal and open a new one. This forces VS Code to re-run the activation sequence.
Troubleshooting: When VS Code Gets Confused
Sometimes, VS Code might "hang onto" the old system interpreter, especially if you opened the project before creating the venv folder. If you encounter errors where import statements are underlined in red (meaning the IDE can't find your installed packages), follow this checklist:
Check the Status Bar: Look at the bottom-right of the VS Code window. Does it show the correct path to your project's venv? If not, click it and re-select the correct one.
Restart the Language Server: Sometimes the Python extension's background process gets stuck. Use the Command Palette (Ctrl+Shift+P) and search for "Python: Restart Language Server".
By aligning your CLI workflow with VS Code’s interpreter selection, you ensure that your code-writing experience is perfectly synced with the reality of your filesystem.
Even with your isolated venv sandbox, you are only halfway to a truly portable project. What happens if you move to a new computer, or if your friend wants to run your project code? They don't have your venv folder, and they definitely shouldn't try to use your local files.
Dependency management is how you document exactly which libraries (and which specific versions) your project needs to function.
The requirements.txt File
The industry standard for tracking dependencies in a Python project is a simple text file named requirements.txt. It lists every package you’ve installed inside your environment.
Capturing Your Environment
When you are satisfied with your project and have installed your necessary packages, you can "freeze" the state of your environment. This creates a list of every package and its exact version number.
Run this command inside your activated venv:
$ pip freeze > requirements.txt
If you open the resulting requirements.txt file (using gnome-text-editor or cat), you’ll see something like:
Plaintext
pytest==8.0.0
requests==2.31.0
Recreating the Environment
When you clone your project from a repository or move it to a new machine, you don't need to hunt down every library manually. You simply create a new venv, activate it, and run the install command. Create and activate your new venv first:
$ python3 -m venv venv
$ source venv/bin/activate
Install everything listed in your file:
$ pip install -r requirements.txt
If you are using Git, version control is key. There is one Golden Rule of Python dependency management:
Never commit your venv folder to Git
The venv folder is massive, contains local system-specific binaries, and is not portable. Instead, you should:
Add venv/ to your .gitignore file.
Commit your requirements.txt file to your repository.
By tracking only the requirements.txt file, you allow anyone (or any future version of yourself) to pull your code and recreate the exact environment needed to run it, without cluttering your repository with environment binaries.
That's it for now. My suggestion, is to use sandboxed environments for your Python Projects.
Quick Reference >>
