Vous avez installé Anaconda pour travailler en data science, puis un tutoriel vous demande de lancer pip install pour un paquet introuvable sur conda. Quelques jours plus tard, votre environnement refuse de résoudre la moindre dépendance. Ce scénario est fréquent : conda et pip gèrent les paquets Python chacun de leur côté, et l’un ignore ce que l’autre a installé.
Faire cohabiter pip et conda sans casse est possible, à condition de respecter un ordre précis et d’isoler chaque projet dans son propre environnement.
A lire en complément : Touche Shift sur le clavier : usages cachés sous Windows et macOS
Pourquoi conda et pip entrent en conflit
Conda installe des paquets depuis ses propres dépôts (Anaconda repository, conda-forge). Il gère aussi des bibliothèques système non-Python (C, Fortran, CUDA). Pip, lui, tire ses paquets exclusivement depuis PyPI. Les deux outils écrivent dans le même dossier site-packages, mais conda ne voit pas les paquets installés par pip.
Quand vous lancez ensuite conda install ou conda update, le solveur de dépendances de conda recalcule l’arbre complet des paquets qu’il connaît. Il peut alors écraser une version installée par pip, ou installer une version incompatible avec un paquet pip déjà présent. Le résultat : des erreurs d’import, des segfaults, ou un environnement que conda déclare « broken ».
A lire également : Parse XML using Python dans Django et Flask pour vos APIs
Ce problème ne vient pas d’un bug. Il vient du fait que deux gestionnaires de dépendances coexistent sans partager leur base de données.
Environnement conda dédié : la première barrière contre la casse
La règle la plus protectrice est aussi la plus simple : ne jamais installer pip dans l’environnement base d’Anaconda. L’environnement base est celui qui se charge par défaut quand vous ouvrez un terminal après avoir installé Anaconda. Il contient des centaines de paquets préinstallés, et toute modification risque de déstabiliser l’ensemble.
Créez un environnement dédié pour chaque projet :
conda create -n mon-projet python=3.11
Activez-le avant toute installation :
conda activate mon-projet
Cette isolation garantit que les paquets pip d’un projet ne polluent pas un autre. Si l’environnement casse, vous le supprimez et le recréez sans toucher au reste de votre installation Anaconda.
Vérifier quel pip vous utilisez
Après activation, tapez which pip (Linux/macOS) ou where pip (Windows). Le chemin retourné doit pointer vers le dossier de votre environnement conda, pas vers un Python système ou un autre environnement. Si le chemin pointe ailleurs, le pip que vous utilisez installera les paquets au mauvais endroit.
Ordre d’installation : conda d’abord, pip ensuite
Vous avez peut-être l’habitude de mélanger conda install et pip install au fil de vos besoins. Cette approche finit toujours par poser problème. La documentation officielle d’Anaconda recommande un ordre strict :
- Installez d’abord tous les paquets disponibles via conda (
conda install numpy pandas scikit-learn) - Installez ensuite, et seulement ensuite, les paquets absents de conda via pip (
pip install mon-paquet-pypi) - Après avoir utilisé pip, évitez de relancer
conda installdans cet environnement, car le solveur conda ne tiendra pas compte des paquets pip
Toute installation conda après un pip install risque de casser l’environnement. Si vous devez ajouter un paquet conda après coup, la solution la plus sûre consiste à recréer l’environnement en reprenant l’ordre correct.
Que faire quand un paquet existe sur conda et PyPI
Privilégiez systématiquement la version conda. Conda résout les dépendances binaires (compilateurs, bibliothèques C) que pip ne gère pas. Par exemple, un paquet comme scipy installé via conda embarque ses propres binaires optimisés, tandis que la version pip peut nécessiter un compilateur local.
Vérifiez la disponibilité conda avec conda search nom-du-paquet. Si le paquet n’apparaît pas dans le canal par défaut, essayez conda-forge : conda install -c conda-forge nom-du-paquet.
Figer les dépendances d’un projet avec un fichier environment.yml
Un fichier environment.yml permet de déclarer à la fois les paquets conda et les paquets pip dans un seul document. C’est le moyen le plus fiable de reproduire un environnement sur une autre machine ou après une réinstallation.
Voici la structure type :
name: mon-projetchannels: - conda-forge - defaultsdependencies: - python=3.11 - numpy - pandas - pip: - mon-paquet-pypi
La section pip est imbriquée sous dependencies, ce qui signale à conda que ces paquets seront installés par pip après les paquets conda. L’ordre d’installation reste donc respecté automatiquement.
Pour créer l’environnement à partir de ce fichier : conda env create -f environment.yml. Pour le mettre à jour après modification : conda env update -f environment.yml --prune. Le flag --prune supprime les paquets retirés du fichier.
Alternatives à pip sous Anaconda : poetry et venv
Certains développeurs préfèrent utiliser poetry ou venv plutôt que le couple conda/pip. Ces outils résolvent le même problème (isolation et gestion de dépendances) mais avec des approches différentes.
- venv + pip : l’environnement virtuel natif de Python. Léger, il ne gère que les paquets Python depuis PyPI. Pas de prise en charge des bibliothèques C ou des versions de Python elles-mêmes
- poetry : un gestionnaire de projet qui combine déclaration de dépendances, résolution de versions et publication sur PyPI. Il utilise pip en arrière-plan mais verrouille les versions dans un fichier
poetry.lock - conda seul : adapté quand tous vos paquets existent sur les dépôts conda. Pas besoin de pip dans ce cas
Si votre projet mélange des paquets conda (pour le calcul scientifique ou le GPU) et des paquets PyPI spécialisés, la combinaison conda + pip avec un fichier environment.yml reste la plus adaptée. Si votre projet est purement Python sans dépendances binaires complexes, venv + pip ou poetry suffisent, et vous évitez la question de la cohabitation.
Diagnostiquer un environnement conda cassé par pip
Votre environnement affiche des erreurs d’import ou des messages de conflit après un pip install ? Commencez par lister ce que pip a installé : pip list. Comparez avec la liste conda : conda list. Les paquets installés par pip apparaissent avec la mention pypi dans la colonne « Channel ».
Si un même paquet apparaît dans les deux listes avec des versions différentes, c’est la source du conflit. Recréer l’environnement proprement reste plus rapide que tenter de réparer manuellement. Exportez d’abord votre configuration : conda env export > environment.yml, éditez le fichier pour nettoyer les versions problématiques, puis recréez avec conda env create -f environment.yml.
La cohabitation entre pip et conda fonctionne de manière prévisible quand on respecte trois principes : un environnement dédié par projet, conda avant pip, et un fichier environment.yml pour verrouiller le tout. Le reste n’est que discipline.
