Question
venv recreation vs. conda revision history for environment recovery
Mira Moss
0 reputation · 08 Feb 2022, 10:05 UTC
125.9K views1
Loading…
0 reputation · 08 Feb 2022, 10:05 UTC
When managing Python environments for production deployments, the strategy for recovering from a failed dependency upgrade differs significantly between the standard library venv module and the Conda package manager.
The venv approach relies on a lightweight footprint, where recovery typically involves deleting the environment directory and recreating it from a requirements.txt file. In contrast, Conda manages the Python interpreter itself and maintains a revision history, allowing for a state-based rollback to a previous installation point.
The primary constraint is the balance between disk space overhead and the speed of restoration during a failure event.
venv rebuild?venv?For binary‑dependency recovery, a Conda revision rollback is more reliable only if the local package cache still contains the exact builds that were previously installed. When the cache is intact, rolling back restores the precise binaries that Conda originally fetched. A venv recreate from requirements.txt will always reinstall the latest compatible wheels (or source builds) available at recreation time, which can differ in ABI or version, making it less reliable for binary‑specific reproducibility.
Regarding disk overhead, Conda’s package cache (typically several hundred megabytes to a few gigabytes) adds a fixed cost per workstation, while each venv occupies only the space of its installed packages. The cache becomes a limiting factor when you maintain many environments or when total available storage is constrained; roughly, once the cache exceeds ~5 GB or you need to keep more than 10–20 isolated environments on the same disk, the overhead outweighs the benefit of instant rollback.
pythonconda list --revisions) and can attempt to revert with conda install --revision N.conda clean --packages removes them and makes rollback impossible).venv stores absolute paths to the Python interpreter; the supported recovery path is deleting the directory and running python -m venv .venv && pip install -r requirements.txt.requirements.txt but does not capture the Python interpreter version, system libraries, or packages installed via pip inside a conda env.conda clean --info shows the cache size and location; if it has been recently cleaned, assume older revisions may be missing.conda list --revisions # note the revision number before the failure
conda install --revision <N> # roll back to that state# remove the broken environment
rm -rf /path/to/env
# recreate from a pinned requirements.txt
python -m venv /path/to/env
source /path/to/env/bin/activate
pip install -r requirements.txt
conda list and compare output to the expected revision.pip freeze and diff against the original requirements.txt.If you are uncertain whether the package cache has been cleared (e.g., after a conda clean --packages or automated cleanup), please confirm the cache state before deciding to rely on revision rollback; this detail changes the recommendation from "use rollback" to "recreate the environment".
Use comments to ask for clarification. Post a solution as an answer.
5,840 reputation · 08 Feb 2022, 15:00 UTC
Two practical nuances worth adding:
pkgs cache. In Docker or CI where each layer is a separate filesystem, every conda create copies packages anew, eliminating the space advantage. venv with a shared system Python avoids this entirely.pkgs cache. A requirements.txt or uv.lock file is portable by design and works with any Python interpreter of the same version.For production, a hybrid pattern often works best: Conda for the base interpreter + binary-heavy stack (NumPy, CUDA toolkit) with revisions enabled, and a pip-tools/uv-managed requirements.txt layered on top for pure-Python app dependencies. This keeps rollback fast for the brittle binary layer while keeping the application layer portable and auditable.