Quando un piccolo ufficio prende in gestione un’applicazione Python o configura un nuovo computer, l’insieme dei pacchetti dell’applicazione dovrebbe essere tracciabile. Con venv e pip è possibile predisporre una ricreazione controllata dell’ambiente. Sono determinanti un ambiente iniziale pulito, dipendenze verificate e test dell’applicazione. La sola esportazione dei pacchetti non garantisce una riproducibilità universale.
1. Definire i prerequisiti e la directory di lavoro
Tutti gli esempi Unix seguenti devono essere eseguiti esclusivamente in un progetto di test separato, non nella directory dell’applicazione in produzione. È necessario disporre di un interprete Python già installato, mantenuto aggiornato e compatibile con il progetto. Documentate in anticipo:
- la versione prevista dell’interprete, inclusa la versione secondaria,
- il sistema operativo e l’architettura del processore,
- lo stato del progetto, la configurazione necessaria e i test dell’applicazione disponibili.
python3 indica qui l’interprete scelto consapevolmente. Prima di iniziare, verificate a quale interprete corrisponde; se necessario, utilizzatene il percorso esplicito. Non sostituite il Python del sistema operativo e non modificate il PATH globale. Tutti i percorsi relativi fanno riferimento alla directory radice del progetto di test. I nomi di file come requirements-snapshot.txt sono esempi scelti liberamente e, se modificati, devono essere aggiornati in modo coerente ovunque.
2. Preparare un ambiente di origine pulito
Create un ambiente dedicato, inizialmente pulito, per lo stato previsto del progetto:
python3 -m venv .venv-srcInstallatevi esclusivamente le dipendenze previste per il progetto di test, seguendo le relative istruzioni di installazione. Utilizzate esplicitamente .venv-src/bin/python -m pip, per evitare di intervenire per errore su un altro ambiente. Non importate un insieme di pacchetti non verificato da un ambiente di lavoro condiviso e non eseguite aggiornamenti indiscriminati dei pacchetti.
Secondo la documentazione di venv, i pacchetti del progetto sono isolati per impostazione predefinita. L’ambiente rimane tuttavia legato al proprio interprete di base e non è una sandbox di sicurezza. Se si utilizzano percorsi espliciti degli interpreti, non è necessaria l’attivazione. A questo punto testate l’applicazione con dati di prova adeguati; solo successivamente procedete all’esportazione.
3. Registrare e verificare lo stato dei pacchetti sottoposto a test
.venv-src/bin/python -m pip freeze > requirements-snapshot.txtpip freeze elenca i pacchetti installati. Non è un risolutore di lockfile e, per impostazione predefinita, esclude alcuni pacchetti di bootstrap. Il file è quindi un’istantanea iniziale, non una descrizione completa dell’interprete, degli strumenti e della piattaforma.
Aprite il file esportato prima di ogni condivisione. Controllate in particolare le installazioni modificabili, i percorsi locali e gli URL dei pacchetti privati. Rimuovete le credenziali dai file condivisi. Chiarite al contempo come mantenere accessibili, con le necessarie autorizzazioni, i pacchetti privati richiesti; la semplice eliminazione di queste voci non rende completa la ricreazione dell’ambiente. Registrate le dipendenze dirette e transitive, anziché elencare soltanto le librerie utilizzate direttamente.
4. Ricreare l’ambiente in modo indipendente e verificarlo
Lasciate .venv-src invariato. Create accanto a esso il secondo ambiente con un interprete adatto e compatibile, quindi installate l’elenco verificato:
python3 -m venv .venv-rebuild
.venv-rebuild/bin/python -m pip install -r requirements-snapshot.txt
.venv-rebuild/bin/python -m pip checkpip check verifica esclusivamente la compatibilità delle dipendenze dichiarate. Un risultato senza anomalie non sostituisce né i test dell’applicazione né una verifica di sicurezza. Eseguite quindi le stesse verifiche funzionali effettuate nell’ambiente di origine: per esempio un’importazione prevista, un ciclo di elaborazione tipico e il controllo dei risultati. Avviate esplicitamente anche queste verifiche con .venv-rebuild/bin/python. Documentate gli errori e i risultati dei test prima di accettare l’ambiente ricreato.
5. Documentare più dettagliatamente la piattaforma e i file dei pacchetti
Per una maggiore tracciabilità, registrate anche le versioni di Python e pip utilizzate, oltre al sistema operativo e all’architettura. Secondo la guida di pip alle installazioni ripetibili, dipendenze dirette e transitive con versioni interamente fissate e hash dei pacchetti verificati possono rendere la procedura ancora più sicura. Gli hash confermano che i file dei pacchetti corrispondono a quelli attesi, non che siano privi di software malevolo. Gli archivi wheel possono essere specifici per una piattaforma; pertanto, un insieme di pacchetti disponibile su un’architettura diversa non è automaticamente equivalente.
6. Garantire la possibilità di ripristino e registrare il risultato
Conservate l’ambiente precedente e una copia di sicurezza dell’applicazione e dei dati finché il nuovo ambiente non sarà stato verificato. In caso di errori, eliminate soltanto il nuovo ambiente di test e indagatene la causa; la base di lavoro precedente rimane intatta. Gli ambienti virtuali vanno ricreati, non spostati o copiati.
Conclusione: Una ricreazione utilizzabile comprende un’esportazione verificata dei pacchetti, una piattaforma documentata e test dell’applicazione superati. Questa combinazione rende tracciabili le modifiche, senza confondere un elenco di pacchetti con una garanzia completa di riproducibilità.