Mélanger pip et conda dans un même environnement Anaconda ou Miniconda casse la résolution de dépendances. Le solveur conda ne suit pas les paquets installés par pip, et pip ignore les métadonnées conda. Le résultat : des bibliothèques en double, des versions incompatibles, et un environnement qu’il faut souvent recréer de zéro. Nous détaillons ici les mécanismes précis de ces conflits et les pratiques qui les neutralisent.
Solveur conda et métadonnées pip : deux systèmes de résolution qui s’ignorent
Conda résout les dépendances avant l’installation. Son solveur (libmamba depuis les versions récentes) analyse l’arbre complet des paquets, y compris les bibliothèques C/C++ et les runtimes système. Il produit un graphe cohérent, puis installe tout d’un bloc.
Pip fonctionne autrement. Il résout les dépendances de manière séquentielle, paquet par paquet, en s’appuyant sur les métadonnées PyPI. Il ne connaît ni les paquets conda ni les bibliothèques partagées (.so, .dll) gérées par conda.
Le problème concret : quand pip installe un paquet, il l’écrit dans le répertoire site-packages de l’environnement, mais ne met pas à jour la base de données conda. Au prochain conda install, le solveur ne voit pas ce que pip a posé. Il peut alors écraser une dépendance, installer une version différente d’une bibliothèque partagée, ou créer un doublon avec deux versions du même paquet.
Nous observons que ce conflit s’est intensifié ces dernières années. Les arbres de dépendances grossissent, les paquets scientifiques (NumPy, SciPy, PyTorch) embarquent des binaires liés à des versions précises de CUDA, MKL ou OpenBLAS, et le moindre décalage de version provoque des erreurs au runtime, pas à l’installation.
Miniconda plutôt qu’Anaconda pour limiter la surface de conflit pip
Anaconda distribue un environnement base qui contient plus d’un millier de paquets préinstallés. Chaque paquet préinstallé est une contrainte supplémentaire pour le solveur. Quand on lance pip dans cet environnement base, la probabilité de collision avec un paquet conda existant est élevée.
Miniconda réduit cette surface d’exposition. Il n’installe que conda, Python et quelques dépendances minimales. L’environnement base reste léger, et nous recommandons de ne jamais y installer de paquet de travail, ni avec conda ni avec pip.
La bonne pratique consiste à créer un environnement dédié par projet :
conda create -n monprojet python=3.12crée un environnement isolé avec la version Python souhaitée, sans hériter des paquets du baseconda activate monprojetactive cet environnement avant toute installation- Toute commande pip lancée dans cet environnement n’affecte que lui, ce qui limite la casse en cas de conflit à un seul projet
Un environnement corrompu par un conflit pip/conda se supprime et se recrée en quelques secondes avec Miniconda. Avec Anaconda, la reconstruction de l’environnement base est longue et parfois imprévisible.
Ordre d’installation pip et conda : la règle qui évite la majorité des conflits
La séquence d’installation compte autant que le choix des outils. Installer d’abord tous les paquets conda, puis les paquets pip en dernier. Cette règle n’est pas un conseil de confort, elle découle directement du fonctionnement des deux solveurs.
Conda construit un graphe de dépendances global. Si on installe un paquet pip entre deux installations conda, le solveur conda recalcule son graphe sans tenir compte du paquet pip. Il peut alors rétrograder ou remplacer une bibliothèque dont le paquet pip dépend.
Workflow concret pour un projet data
Voici la séquence que nous appliquons :
- Créer l’environnement :
conda create -n projet python=3.12 - Installer les paquets lourds (NumPy, pandas, scikit-learn, PyTorch) via
conda install - Vérifier la cohérence :
conda listpour confirmer les versions - Installer les paquets absents du canal conda via
pip install paquet, uniquement après que conda a terminé - Ne plus lancer
conda installaprès avoir utilisé pip dans cet environnement
Ce dernier point est le plus souvent violé. Ajouter un paquet conda après pip force une re-résolution qui ignore les paquets pip. C’est là que l’environnement se corrompt.
Fichier environment.yml : verrouiller les dépendances pip et conda ensemble
Le fichier environment.yml permet de déclarer les deux sources dans un seul manifeste. Conda le lit nativement et respecte l’ordre : il installe d’abord ses propres paquets, puis exécute pip pour le reste.
Un exemple minimal :
name: monprojetchannels: - conda-forge - defaultsdependencies: - python=3.12 - numpy - pandas - pip - pip: - flask - requests
Déclarer pip comme dépendance conda est obligatoire dans ce fichier. Sans cette ligne, conda utilise le pip système, qui installe les paquets hors de l’environnement ou dans un chemin inattendu.
L’avantage principal : la commande conda env create -f environment.yml reproduit un environnement identique sur une autre machine. Les versions pip et conda sont figées au même endroit, ce qui élimine les écarts entre postes de développement.
Mettre à jour sans casser l’environnement
Pour ajouter un paquet après la création, modifier le fichier yml puis lancer conda env update -f environment.yml --prune. Le flag --prune supprime les paquets retirés du fichier. Cette approche est plus fiable que des conda install ou pip install manuels successifs, car elle maintient le fichier yml comme source de vérité unique.
Alternatives récentes : uv et pixi face au couple pip/conda
Le couple pip/conda n’est plus la seule option. Deux outils récents méritent l’attention des équipes qui veulent sortir de cette cohabitation fragile.
uv, écrit en Rust, remplace pip avec une résolution de dépendances rapide et un verrouillage natif. Il ne gère pas les paquets conda, mais pour les projets Python purs (sans dépendances C/Fortran complexes), il supprime le besoin de pip dans un environnement conda.
pixi se positionne comme un gestionnaire d’environnements compatible avec les canaux conda-forge, tout en intégrant la gestion des paquets PyPI. Il unifie les deux sources de paquets dans un seul solveur, ce qui élimine le problème de métadonnées séparées décrit plus haut.
Ces outils ne remplacent pas conda pour tous les cas (gestion de CUDA, de bibliothèques Fortran, de runtimes R), mais ils réduisent les situations où mélanger pip et conda est nécessaire.
Le choix entre ces approches dépend du type de projet. Pour du machine learning avec des dépendances GPU, conda reste le gestionnaire le plus adapté, à condition de respecter l’ordre d’installation et d’isoler chaque projet dans son environnement. Pour des applications web ou des microservices Python, migrer vers uv ou pixi supprime le problème à la racine.
