Python 3.10 ha raggiunto la fine del ciclo di vita upstream il 1° ottobre 2026. L’ultima versione di sicurezza è 3.10.22. Non ci sono ulteriori aggiornamenti upstream. Il supporto del produttore deve essere verificato separatamente. La compatibilità specifica dell’applicazione deve essere testata singolarmente.
Creare un inventario del progetto
Prima che una migrazione abbia luogo, è importante creare un inventario completo del progetto. Questo include tutti i pacchetti utilizzati, le dipendenze e la versione corrente dell’interprete Python. Questo inventario aiuta a rilevare potenziali problemi di compatibilità in anticipo e a pianificare soluzioni.
Verificare la compatibilità del produttore e dei pacchetti
La compatibilità deve essere verificata in modo sistematico, considerando non solo la versione di Python, ma anche tutte le librerie dipendenti e le loro versioni. Le interfacce esterne, come i driver per database o le API, devono essere verificate per il loro supporto alla versione di destinazione. Per i pacchetti binari, la compatibilità tra piattaforma e architettura è decisiva. La pianificazione deve stabilire responsabilità chiare e finestre di manutenzione per poter rispondere rapidamente ai problemi. È importante suddividere i passaggi di migrazione in fasi e verificare l’impatto su tutta l’applicazione in ogni passo. Una migrazione generica senza analisi preliminare può portare a errori inaspettati.
Le informazioni del produttore sulle versioni supportate sono qui di fondamentale importanza.
Backup dell’applicazione, dei dati e della configurazione
Prima di iniziare la migrazione, l’applicazione, i dati e le configurazioni devono essere salvati integralmente in copie di sicurezza. L’ambiente vecchio deve rimanere invariato per poterlo utilizzare in caso di problemi.
Progetto di test e controllo dell’interprete
I comandi mostrati sono esempi per Unix; tutti i comandi vengono eseguiti nella radice di un progetto di test separato; i percorsi relativi si riferiscono ad esso. Prima dell’uso verificare la versione effettiva di python3. La versione di destinazione deve già essere installata, tuttora supportata e compatibile con il progetto. Non verrà modificato nessun servizio in produzione.
Il progetto di test serve per verificare in modo isolato i passaggi di migrazione e non deve essere confuso con gli ambienti di produzione. Prima dell’inizio della migrazione determinare la versione corrente di Python nell’ambiente di utilizzo e confrontarla con la versione di destinazione. Tutti i comandi nel progetto di test sono esemplificativi e servono per la dimostrazione; devono essere adattati all’ambiente specifico.
Prima dell’installazione l’interprete python3 deve già essere installato, tuttora supportato e compatibile con il progetto. Il file requirements-reviewed.txt è una lista di pacchetti preparata autonomamente e testata sulla versione di destinazione e non è un file incluso. Non deve essere sostituito il Python del sistema operativo. Non deve essere modificato il PATH globale. Non sono consigliati aggiornamenti generici dei pacchetti. I seguenti comandi devono essere utilizzati nel progetto di test:
python3 --version
python3 -m venv .venv-next
.venv-next/bin/python -m pip install -r requirements-reviewed.txt
.venv-next/bin/python -m pip checkInstallazione e verifica delle dipendenze
pip check verifica esclusivamente la compatibilità dichiarata delle dipendenze. Non vengono eseguiti test sull’applicazione né un audit di sicurezza. Un venv isola i pacchetti, ma non è una sandbox di sicurezza e non risolve la fine del supporto dell’interprete. Gli ambienti devono essere creati nuovamente, non copiati o spostati. L’attivazione non è necessaria se il percorso dell’interprete è specificato esplicitamente.
Test e pianificazione del rollback
L’accettazione della migrazione deve avvenire solo se tutti i test pianificati sono stati completati con successo e non sono emersi errori critici. I dati sensibili devono essere trattati in base alle specifiche del progetto per evitare violazioni delle normative sulla privacy. Prima del passaggio, documentare i risultati attesi e confrontarli con i risultati effettivi. Le differenze devono essere documentate in modo dettagliato e non ignorate semplicemente.
Dopo l’installazione e la verifica delle dipendenze, devono essere testati l’applicazione, i dati di esempio e le integrazioni esterne. I criteri per il test devono essere documentati. Gli ambienti esistenti, comprese l’applicazione e il backup dei dati, devono essere conservati fino all’accettazione. Solo successivamente può essere pianificata una transizione controllata. Un rollback sull’ambiente vecchio è possibile solo come soluzione di transizione e non ripristina il supporto completo.
Per ulteriori informazioni, consultare le documentazioni ufficiali: PEP 619, Documentazione venv, pip check.