1.11 Step | InstallPythonRequirements

Installa le dipendenze pip nel virtualenv. Vive in src/steps/install_python_requirements.rs. Terzo e ultimo dei sotto-step dei sorgenti. Tutte le install come utente odoo, dal pip del venv.

La sua particolarità: non ha un undo proprio.

---

Il cuore concettuale: nessun undo proprio

I pacchetti pip vivono dentro <install_dir>/sandbox (il venv). Se il venv è nostro, l'undo di 1.10 CreateVirtualenv (rm -rf sandbox) li rimuove tutti. Quindi:

undo di questo step → NO-OP documentato. Disinstallare i pacchetti uno a uno sarebbe ridondante e fragile: la rimozione del venv è l'undo corretto.

Un undo in meno da scrivere, per la ragione giusta. Se il venv era Preexisting, non tocchiamo comunque i pacchetti di un venv altrui.

---

Ciclo di vita

Fase	Comportamento
snapshot	leggero: lo stato rilevante per il rollback è quello del venv (1.10), non un PreState per-pacchetto
run	legge requirements.txt (assente → errore), poi la sequenza pip qui sotto. dry_run → log
undo	NO-OP (vedi sopra)

---

Workaround Cython/gevent (fix reale, da preservare)

Cython 3 ha rimosso il tipo long di Python 2; gevent (richiesto da Odoo 18) usa ancora quel codice nei .pyx. pip costruisce le wheel in un ambiente isolato che ignora il Cython del venv. La soluzione (fedele al Bash) è una sequenza precisa:

1. pip install --upgrade pip wheel
2. pip install "Cython<3"                              # nel venv
3. pip install --no-build-isolation <gevent-spec>      # usa il Cython<3 locale
4. pip install --prefer-binary -r <requirements senza gevent>

• La spec di gevent è estratta da requirements.txt (es. gevent==21.12.0), togliendo marker d'ambiente (;…) e commenti (#…) — che --no-build-isolation non tollera.
• Il passaggio 4 usa un requirements filtrato senza le righe gevent, altrimenti pip lo ricompilerebbe da sorgente nell'env isolato, ignorando il Cython<3.

Non è un residuo: è un fix reale. extract_gevent_spec e filter_out_gevent sono funzioni pure, testate a parte; la sequenza pip è verificata in ordine.

---

La cache di pip vive nel nostro perimetro (A-R5-3)

pip mette la sua cache in $HOME/.cache, e l'$HOME dell'utente odoo è /opt/odoo — la directory che l'installer, se la trova già esistente, marca Preexisting e non tocca mai. Risultato misurato in CI: dopo un rollback completo, /opt/odoo/.cache restava lì. Cache rigenerabili, ma la promessa è «il sistema torna esattamente com'era».

La correzione è preventiva, non una pulizia: ogni invocazione passa --cache-dir <install_dir>/sandbox/.pip-cache, cioè dentro il venv, che l'undo di 1.10 CreateVirtualenv rimuove per intero con un rm -rf. Niente nasce fuori dal perimetro, quindi non serve inseguire nulla con euristiche di cancellazione dentro la home del cliente. E resta una cache: un secondo giro dell'installer la ritrova e non riscarica le wheel.

Perché non <install_dir>/.pip-cache, un livello più su: l'undo di 1.9 CloneOdooRepo rimuove install_dir solo se vuota. Una cache lì la bloccherebbe — il residuo si sposterebbe di un livello invece di sparire.

Copre pip, non tutto. La prima installazione arrivata in fondo in CI ha mostrato che /opt/odoo/.cache rinasce comunque: nella home dell'utente odoo scrivono anche odoo-bin e il servizio (fontconfig, e il selfcheck di pip fino alla 23, che ignora --cache-dir). Inseguire i produttori è una battaglia che si perde; la copertura generale è 1.3b SetupCacheDir, che possiede la directory. Questo --cache-dir resta perché tiene comunque fuori dalla home le centinaia di MB di wheel.

---

Note di design

• Tutte le install via sudo -u odoo <venv>/bin/pip (privilegio minimo), con --cache-dir nel venv.
• Snapshot serializza solo un flag "installato" per il riepilogo — non guida alcun undo.
• Test: undo no-op (nessuna disinstallazione, la rimozione pip è di 1.10), sequenza gevent/Cython in ordine, requirements.txt mancante → errore, estrazione/filtro gevent puri.