Python venv Feuille de rappel
quelques commandes utiles pour venv
Venv est un outil de gestion des environnements virtuels depuis la ligne de commande. Beaucoup plus simple que Anaconda. Voici quelques commandes utiles de venv.
Feuille de rappel de venv Python
Créer un environnement virtuel
-
Commande standard (Python 3.3+):
python -m venv venv
Cela crée un environnement virtuel nommé
venv
dans votre répertoire actuel. -
Avec une version spécifique de Python (si installée):
python3.10 -m venv venv
ou en utilisant
virtualenv
:virtualenv -p /usr/local/bin/python3.10 venv
(Requiert le package
virtualenv
).
Activer l’environnement virtuel
- Sous Windows:
.\venv\Scripts\activate
- Sous macOS/Linux:
Le prompt de la shell devrait maintenant afficher le nom de l’environnement.source venv/bin/activate
Désactiver l’environnement virtuel
- Tous les plateformes:
Cela vous ramène à votre Python système.deactivate
Installer des paquets
- Avec pip:
Exemple:pip install
pip install numpy pandas
- Mettre à jour pip (recommandé):
python -m pip install --upgrade pip
Geler et exporter les dépendances
- Enregistrer les paquets de l’environnement actuel:
pip freeze > requirements.txt
- Installer à partir du fichier requirements:
Assurez-vous que votre environnement virtuel est activé avant d’exécuter ces commandes.pip install -r requirements.txt
Supprimer un environnement virtuel
deactivate
rm -rf <chemin de l'environnement>
Pièges courants lors de la gestion des environnements virtuels Python
Oublier d’activer l’environnement virtuel
- Une erreur fréquente est d’exécuter des commandes sans avoir activé l’environnement virtuel souhaité, ce qui entraîne l’installation de paquets dans l’environnement global ou le mauvais venv. Cela peut provoquer des conflits de dépendances et un comportement imprévisible.
Ne pas fixer les versions des paquets
- L’utilisation de spécificateurs de version trop larges (comme
>=
au lieu de==
) dansrequirements.txt
compromet la reproductibilité. Le fixage des versions exactes garantit que tout le monde travaillant sur le projet utilise les mêmes versions de paquets, évitant ainsi les problèmes imprévisibles lors du déploiement ou de la collaboration.
Mélanger les environnements globaux et virtuels
- Installer accidentellement des paquets globalement ou mélanger les environnements globaux et virtuels peut créer des conflits, surtout si différents projets nécessitent des versions de paquets incompatibles. Assurez-vous toujours d’opérer dans l’environnement correct.
Inclure les environnements virtuels dans le contrôle de version
- Inclure le répertoire de l’environnement virtuel (par exemple,
venv/
) dans le contrôle de version encombre les dépôts et est inutile. Ajoutez toujours les répertoires venv à.gitignore
pour garder votre dépôt propre.
Négliger de séparer les dépendances de développement et de production
- Ne pas distinguer les dépendances de développement et de production peut entraîner des déploiements encombrés ou peu sécurisés. Utilisez des fichiers requirements séparés ou des sections de configuration pour chacun.
Manque de documentation et d’automatisation
- Ne pas documenter les étapes de configuration de l’environnement ou échouer à automatiser le processus (avec des scripts ou des Makefiles) rend plus difficile l’intégration de nouveaux contributeurs et la reproduction des environnements.
Ne pas nettoyer régulièrement les anciens environnements
- Au fil du temps, les environnements virtuels inutilisés peuvent s’accumuler, gaspillant de l’espace disque et causant de la confusion. Supprimez régulièrement les venvs obsolètes pour maintenir un espace de travail propre.
Ignorer les limites du Python système et des gestionnaires de paquets
- Modifier le Python système ou mélanger les gestionnaires de paquets système avec pip peut casser les outils système et introduire des problèmes difficiles à diagnostiquer. Utilisez toujours des venvs pour les dépendances de projet et évitez d’interférer avec les paquets gérés par le système.
Tableau récapitulatif
Piège | Impact |
---|---|
Oublier d’activer le venv | Installe les paquets dans le mauvais environnement |
Ne pas fixer les versions des paquets | Builds imprévisibles, bugs difficiles à reproduire |
Mélanger les environnements globaux et virtuels | Conflits de dépendances/versions |
Inclure les répertoires venv dans le contrôle de version | Dépôts encombrés, désordonnés |
Ne pas séparer les dépendances de développement et de production | Déploiements encombrés/insecure |
Manque de documentation/automatisation | Difficulté d’intégration, configurations incohérentes |
Ne pas nettoyer les anciens environnements | Gaspillage d’espace disque, confusion |
Modifier le Python système ou les paquets | Instabilité système, outils cassés |
Suivre les bonnes pratiques, comme toujours activer votre venv, fixer les dépendances, séparer les environnements et maintenir une documentation claire, peut vous aider à éviter ces pièges courants.
Principales différences entre Conda et les environnements virtuels pour la reproductibilité
Fonction | Environnements Conda | Environnements virtuels Python (venv/virtualenv) |
---|---|---|
Portée de la gestion | Gère les paquets Python et les dépendances non-Python (ex. bibliothèques système, compilateurs) | Gère uniquement les paquets Python via pip |
Contrôle de la version de Python | Peut spécifier et installer n’importe quelle version de Python par environnement | Utilise la version de Python installée sur le système |
Consistance interplateforme | Plus consistante sur différentes OS (Windows, macOS, Linux) en raison de la gestion de toutes les dépendances | Dépend des bibliothèques du système, qui peuvent varier selon l’OS |
Sources de paquets | Utilise les dépôts Conda (binaires précompilés, stack scientifique) | Utilise PyPI (pip) pour les paquets Python |
Reproductibilité | Plus élevée pour les projets complexes, scientifiques ou multilingues ; peut exporter l’environnement complet (conda env export ) |
Bonne pour les projets purement Python ; peut manquer de reproductibilité si des dépendances système sont impliquées |
Dépendances non-Python | Peut installer et gérer (ex. OpenBLAS, libpng) | Ne peut pas gérer ; doivent être installés séparément |
Export/Import d’environnement | conda env export / conda env create pour une reproductibilité complète |
pip freeze > requirements.txt / pip install -r requirements.txt (uniquement les paquets Python) |
Performance | Plus rapide et plus fiable pour les grands paquets scientifiques (ex. numpy, pandas) | Peut nécessiter la compilation depuis la source, surtout sous Windows |
Complexité | Un peu plus de surcharge de configuration et de gestion | Léger, idéal pour les projets Python simples |
Résumé des points clés
-
Les environnements Conda sont idéaux pour la reproductibilité dans les projets nécessitant à la fois des dépendances Python et non-Python, ou lorsque la réplication exacte entre les plateformes est critique. Conda gère l’ensemble de la pile, y compris Python lui-même, les bibliothèques et même les compilateurs, rendant plus facile le partage et la reproductibilité d’environnements complexes, surtout dans les contextes de science des données et de recherche.
-
Les environnements virtuels Python (
venv
/virtualenv
) sont légers et excellents pour isoler les dépendances Python dans les projets purement Python. Cependant, ils ne gèrent pas les dépendances de niveau système ou non-Python, donc la reproductibilité peut être compromise si votre projet dépend de bibliothèques externes ou de configurations système spécifiques. -
Exporter et partager des environnements : Conda vous permet d’exporter une spécification complète de l’environnement (
conda env export
), y compris toutes les dépendances et leurs versions, qui peuvent être recréées exactement ailleurs. Avec les environnements virtuels,pip freeze
ne capture que les paquets Python, pas les dépendances système ou la version de l’interpréteur Python. -
Conclusion
Utilisez Conda pour une reproductibilité maximale dans les projets scientifiques, interplateformes ou complexes. Utilisez les environnements virtuels Python pour des projets légers en Python pur où les dépendances système ne sont pas un problème.