1.10 Step | CreateVirtualenv

Creates the Python virtualenv in <install_dir>/sandbox, reversibly. It lives in src/steps/create_virtualenv.rs. The second of the three source sub-steps (1.9 CloneOdooRepo → venv → 1.11 InstallPythonRequirements). Runs as the odoo user.

---

Life cycle

Phase	Behaviour
snapshot	does an executable <venv>/bin/python3 exist? → Preexisting/Untracked
run	Preexisting → skip. Otherwise check that the chosen interpreter can create a venv (import ensurepip), then sudo -u odoo <interpreter> -m venv <venv>, then CreatedByUs. dry_run → log
undo	CreatedByUs only: rm -rf <venv>. Idempotent, best-effort

If ensurepip is unavailable → a clear error, rather than an obscure failure further down the line.

Why import ensurepip and not python3 -m venv --help. The venv module is in the standard library and is always there: its --help exits 0 even on a system where creating a virtualenv is impossible. What the python3-venv package actually brings is ensurepip. Asking about the wrong module was a check that could not fail, and the failure arrived later as a raw Python error, with a half-built sandbox.

Which interpreter

Not a hardcoded python3: the one the preflight chose (see Multi-distribution support). On Fedora ≥ 43, where the system Python is newer than Odoo's pins, the venv is built on a python3.13 installed for the occasion.

The precondition's question and the command that creates the venv use the same interpreter: asking python3 about ensurepip and then building the venv with python3.13 would be a check talking about something else. And nothing downstream notices: the venv exposes <venv>/bin/python3 regardless.

---

The undo that absorbs 1.11's

The architectural point: rm -rf sandbox removes not only the venv but every pip package inside it. That is why 1.11 InstallPythonRequirements has no undo of its own: uninstalling packages one by one would be redundant and fragile when removing the container is enough.

rollback (reverse order):
  undo pip   → NO-OP
  undo venv  → rm -rf sandbox   ← removes the venv + every pip package
  undo clone → rm -rf odoo

The container (the venv) owns the removal of its contents (pip). A model for future decompositions.

The sandbox directory also holds the requirements files handed to pip: they are born there rather than in /tmp precisely because it belongs to odoo and is not writable by third parties — and, being inside the reversible perimeter, an interrupted run leaves nothing outside it. See Security.

---

Design notes

• If the venv was Preexisting (not ours), the undo leaves it intact — and consequently its packages too.
• A legitimate rm -rf: the venv is under <install_dir>, our perimeter.
• Tests: absent (creates + undo rm -rf), Preexisting (no-op), missing ensurepip (error), alternative interpreter (the venv is built on it, and the precondition questions it).