Lorsqu’un petit bureau reprend une application Python ou configure un nouvel ordinateur, il doit pouvoir retracer l’ensemble des paquets de cette application. Avec venv et pip, il est possible de préparer une reconstruction contrôlée de cet environnement. Un environnement de départ propre, des dépendances vérifiées et des tests de l’application sont essentiels. Un simple export des paquets ne garantit pas une reproductibilité universelle.
1. Définir les prérequis et le répertoire de travail
Tous les exemples Unix suivants doivent être exécutés exclusivement dans un projet de test distinct, et non dans le répertoire de l’application en production. Ils nécessitent un interpréteur Python déjà installé, maintenu à jour et compatible avec le projet. Consignez au préalable :
- la version prévue de l’interpréteur, y compris sa sous-version,
- le système d’exploitation et l’architecture du processeur,
- l’état du projet, la configuration nécessaire et les tests disponibles pour l’application.
python3 désigne ici cet interpréteur délibérément choisi. Vérifiez à quel interpréteur cette commande correspond avant de commencer ; utilisez au besoin son chemin explicite. Ne remplacez pas le Python du système d’exploitation et ne modifiez pas le PATH global. Tous les chemins relatifs se rapportent au répertoire racine du projet de test. Les noms de fichiers tels que requirements-snapshot.txt sont des exemples librement choisis et doivent être adaptés partout de manière cohérente en cas de modification.
2. Préparer un environnement source propre
Créez un environnement dédié, initialement propre, pour l’état prévu du projet :
python3 -m venv .venv-srcInstallez-y uniquement les dépendances prévues pour le projet de test, conformément à ses instructions d’installation. Utilisez explicitement .venv-src/bin/python -m pip afin de ne pas cibler un autre environnement par inadvertance. Ne reprenez pas un ensemble de paquets non vérifié provenant d’un environnement de travail partagé et n’effectuez pas de mises à niveau généralisées des paquets.
Selon la documentation de venv, les paquets du projet sont isolés par défaut. L’environnement reste toutefois lié à son interpréteur de base et ne constitue pas un bac à sable de sécurité. Une activation n’est pas nécessaire lorsque les chemins des interpréteurs sont indiqués explicitement. Testez maintenant l’application avec des données de test appropriées ; l’export ne vient qu’ensuite.
3. Capturer et vérifier l’état des paquets testé
.venv-src/bin/python -m pip freeze > requirements-snapshot.txtpip freeze répertorie les paquets installés. Ce n’est pas un solveur de fichiers de verrouillage et il omet par défaut certains paquets d’amorçage. Le fichier constitue donc un instantané de départ, et non une description complète de l’interpréteur, des outils et de la plateforme.
Ouvrez le fichier exporté avant chaque transmission. Vérifiez en particulier les installations en mode modifiable, les chemins locaux et les URL de paquets privés. Supprimez les identifiants d’accès des fichiers transmis. Déterminez également comment les paquets privés nécessaires resteront accessibles avec les autorisations requises ; supprimer simplement ces entrées ne permet pas une reconstruction complète. Consignez les dépendances directes et transitives au lieu de ne répertorier que les bibliothèques directement utilisées.
4. Reconstruire indépendamment et vérifier
Conservez .venv-src sans le modifier. Créez à côté le second environnement avec un interpréteur approprié et compatible, puis installez la liste vérifiée :
python3 -m venv .venv-rebuild
.venv-rebuild/bin/python -m pip install -r requirements-snapshot.txt
.venv-rebuild/bin/python -m pip checkpip check vérifie uniquement la compatibilité des dépendances déclarées. Un résultat sans anomalie ne remplace ni les tests de l’application ni un audit de sécurité. Effectuez donc les mêmes vérifications fonctionnelles que dans l’environnement source : par exemple, une importation prévue, un traitement typique et le contrôle des résultats. Lancez également ces vérifications explicitement avec .venv-rebuild/bin/python. Consignez les erreurs et les résultats des tests avant de valider la reconstruction.
5. Documenter plus précisément la plateforme et les fichiers de paquets
Pour améliorer la traçabilité, consignez également les versions de Python et de pip utilisées, ainsi que le système d’exploitation et l’architecture. Selon le guide de pip sur les installations reproductibles, des dépendances directes et transitives entièrement figées ainsi que des empreintes de paquets vérifiées peuvent renforcer la fiabilité de la procédure. Les empreintes confirment que les fichiers de paquets sont ceux attendus, et non qu’ils sont exempts de logiciels malveillants. Les archives Wheel peuvent être propres à une plateforme ; un ensemble de paquets disponible sur une autre architecture n’est donc pas automatiquement équivalent.
6. Préserver une possibilité de retour en arrière et consigner le résultat
Conservez l’environnement existant ainsi qu’une sauvegarde de l’application et des données jusqu’à ce que le nouvel environnement ait été vérifié. En cas d’erreur, supprimez uniquement le nouvel environnement de test et recherchez la cause ; l’environnement de travail existant reste intact. Les environnements virtuels doivent être recréés, et non déplacés ou copiés.
Conclusion : Une reconstruction exploitable repose sur un export de paquets vérifié, une plateforme documentée et des tests de l’application réussis. Cette combinaison permet de retracer les modifications, sans confondre une liste de paquets avec une garantie complète de reproductibilité.