Python 3.10 après sa fin de vie : repérer les interpréteurs et reconstruire les environnements

Ce que c'est

État au 25 octobre 2026 : le Python Developer's Guide place Python 3.10 dans son tableau des versions non prises en charge, avec une date de fin de vie au 1er octobre 2026. Selon sa définition de cette phase, le cycle de publication est figé et aucune modification supplémentaire n'est autorisée. Vérifier de nouveau ce tableau et la branche de remplacement choisie avant la migration ; un numéro de correctif 3.10 plus élevé n'établit pas une nouvelle période de prise en charge. Cycle de vie du projet amont.

Pourquoi c'est important

L'unité d'inventaire utile est une application avec son interpréteur réel. Vérifier uniquement le shell d'un administrateur laisse de côté les lanceurs de services, les tâches planifiées, les exécuteurs de compilation et les charges de travail conteneurisées. La démarche suivante est une proposition opérationnelle pour repérer et remplacer ces dépendances.

Les environnements Python disposent d'un interpréteur de base et de leurs propres paquets. Leur documentation les considère comme jetables et indique qu'ils ne se prêtent pas à une copie d'un emplacement à un autre. Les recréer à partir des dépendances déclarées au lieu de transférer un ancien environnement dans le déploiement de remplacement. Environnements virtuels.

Comment l'appliquer

• Commencer par les définitions des services, les planifications de tâches, les répertoires des applications et les fichiers de construction des conteneurs. Pour chaque interpréteur applicatif dont l'examen est autorisé, exécuter le diagnostic ci-dessous en remplaçant python par son chemin absolu. Consigner le responsable de la charge de travail et son emplacement de déploiement. Les champs documentés de sys identifient l'exécutable, la version du langage et les préfixes de l'environnement. Champs de l'interpréteur.

  python -c 'import sys; print(sys.executable, sys.version_info[:3], sys.prefix, sys.base_prefix)'
  

• Examiner le fichier pyvenv.cfg de chaque environnement ainsi que la recette de construction et l'inventaire d'exécution de chaque image. Vérifier les étapes de construction comme d'exécution. Traiter un interpréteur absent ou inaccessible comme une lacune de l'inventaire. Pour les paquets fournis par une distribution, obtenir les preuves de prise en charge propres au paquet auprès du distributeur avant de classer cette prise en charge séparément de celle du projet amont.

• Sélectionner une branche prise en charge à la fois par le projet amont et par les dépendances de l'application. Python 3.12 est un exemple de version prise en charge dans le tableau de cycle de vie, pas une destination obligatoire. Une fois cet interpréteur installé dans un environnement de test, créer un environnement neuf avec python3.12 -m venv .venv-next, puis y réinstaller les dépendances examinées du projet selon sa procédure d'installation existante.

• Examiner les notes de version de chaque branche intermédiaire. Pour la transition vers 3.12, rechercher les imports des modules supprimés imp et distutils ainsi que les hypothèses selon lesquelles setuptools est installé par défaut. Mettre à jour le code ou les déclarations de dépendances concernés. Il s'agit de changements de compatibilité documentés, pas d'un classement mesuré des causes d'échec des migrations. Changements de Python 3.12.

• Exécuter .venv-next/bin/python -m pip check et les tests de l'application, y compris son démarrage et des tâches représentatives. La commande pip vérifie la compatibilité des dépendances ; le comportement de l'application nécessite des tests distincts. Reconstruire les images, mettre à jour les chemins de lancement, déployer selon le processus habituel de gestion des changements et répéter le diagnostic de l'interpréteur dans la charge de travail déployée. pip check.

Pièges

Ne pas écraser l'interpréteur système d'une distribution pour réparer une seule application. Conserver un déploiement de retour arrière testé pendant la validation du remplacement et attribuer à tout retour temporaire vers 3.10 un responsable et une date de suppression. Ne clore la migration qu'après avoir également recensé et traité les anciens chemins de lancement, les références d'images et les définitions de tâches inactives. La fin de vie est un constat sur la prise en charge, pas une preuve de compromission du système.