Isolated Environments and Packages
Rebuild Instead of Repair
The project finally has something more valuable than a working environment: it has enough information to replace one.
If the site restored this chapter since your last visit, .venv may already be gone. If it is still present, you do not need to delete it just to follow the explanation. The recovery sequence is the same whenever the directory is missing or you deliberately remove a broken one:
python -m venv .venv
source .venv/bin/activate
python -m pip install -r requirements.txt
python check_package.py
The new piece is -r requirements.txt. It tells pip to read requirements from the file rather than from the rest of the
Recovery is a normal operation
Do not copy .venv from another computer, upload it, or try to repair files inside it by hand. Environments record paths and executable details from the machine that created them. A copied environment may appear present while pointing at the wrong Python underneath.
Removing and rebuilding is usually faster, clearer, and more trustworthy. The environment is not where your project tells its story. requirements.txt is.
The local recovery sequence
On your own machine, these commands use real
python3 -m venv .venv
source .venv/bin/activate
python -m pip install -r requirements.txt
python check_package.py
py -m venv .venv
.\.venv\Scripts\Activate.ps1
python -m pip install -r requirements.txt
python check_package.py
If activation is blocked, use .\.venv\Scripts\python.exe -m pip install -r requirements.txt and .\.venv\Scripts\python.exe check_package.py.
python3 -m venv .venv
source .venv/bin/activate
python -m pip install -r requirements.txt
python check_package.py
You lose .venv but still have requirements.txt. What is the best recovery?
You understand every part of that recovery now. A newer tool can shorten it, but it should not hide what it is shortening.