Avant de se lancer dans les installations il faut comprendre un minimum comment la recherche et le téléchargement des paquetages s’organisent avec conda ou mamba et comment on peut essayer d’avoir des informations sur un paquetage donné.

Article mis à jour en Janvier 2025.

1. Paquetages et canaux

D’une manière générale, un paquetage peut avoir une composante source et une composante binaire avec des liaisons statiques ou dynamiques vers des bibliothèques, qui font partie du paquetage, de la distribution (dépendances) ou externes. Dans le cas le plus simple le paquetage ne dépends d’aucun OS/architecture (noarch) car c’est du code Python pur, dans le cas ou il y a une composante binaire il va dépendre de l’OS (Windows, Linux …) et de l’architecture 32 ou 64 bits (Win-64). Enfin, il va aussi dépendre de la version de Python, puis enfin il va dépendre de sa propre version.
Aujourd’hui les choses sont plus simples, les paquetages sont regroupés dans des canaux de distribution, par exemple defaults (distribution miniconda3) pour Anaconda (noarch ou win64) ou conda-forge pour Conda-Forge (distribution miniconda3 et miniforge3). Les canaux de distribution sont accessibles en utilisant conda ou mamba.

Recherche d’un paquetage

Il y a 3 possibilités: Anaconda, Conda-Forge et PyPI. Dans le cas de PyPI on n’utilisera pas conda/mamba mais pip. Certains paquetages sont disponibles via les 3 sources, mais pas forcément dans le même canal. Prenons le cas du paquetage biopython et faisons une recherche, nous pouvons avoir (extrait):

Source	Commande	Canal	Version	Distribution
Anaconda	conda install conda-forge::biopython	conda-forge	biopython 1.84	miniconda3
Anaconda	conda install main::biopython	main (defaults)	biopython 1.78	miniconda3
Conda-Forge	mamba install biopython conda install biopython	conda-forge (conda-forge)	biopython 1.84	miniforge3
PyPI	pip install biopython	–	biopython 1.84	–

En résumé et simplifié, conda et mamba installent tout (code et composantes binaires), en principe pip était surtout utilisé pour des modules purement Python, mais avec le mécanismes des wheels, du code compilé (lié au paquetage ou nécessité par le paquetage) est intégrable dans l’installation.
Dans le cas de PyPI, ce sont les auteurs qui déposent le paquetage, avec leurs choix personnels pour ce qui vient en plus du code, il n’y a qu’un seul canal. Dans le cas d’Anaconda, c’est Anaconda Inc (une compagnie de droit privé) qui maintient un jeu de paquetages et assure une cohérence (binaires et codes). Un jeu réduit de versions stables (plus anciennes) dans le cas du canal defauts, un jeu plus large, des versions récentes (mais plus expérimentales) dans le cas du canal conda-forge. Les distributions Anaconda (ex: miniconda3) téléchargent et installent à partir de ces deux canaux (et d’autres). Sauf que, le canal conda-forge est maintenu par une communauté libre mais (encore) hébergé par Anaconda. Dans le cas de Conda-Forge c’est cette communauté qui assure la cohérence, et la distribution miniforge3 n’utilise que le canal conda-forge. Dans ce cas, une autre possibilité parfois évoquée mais peu utilisée, est de pouvoir choisir certaines options dans le paquetage, par exemple pour des bibliothèques mathématiques associées (ex: BLAS/libblas), le type d’implémentation (mkl, openblas …) ou sa version.

2. Fichier .condarc

Il s’agit d’un fichier qui permet de spécifier et d’automatiser les canaux à utiliser et leur priorité, par exemple télécharger un paquetage sur conda-forge plutôt que sur defaults. Sous Windows, le fichier est présent dans c:\users\<user_name>, la plupart du temps, les options par défaut sont positionnées à True, et par défaut nous avons une seule ligne :

auto_activate_base: true

On peut aussi vérifier avec la commande conda config ou la commande conda config --show-sources, ce qui va donner :

C:\Dev>conda config --show-sources ==> C:\Users\Xxxx\.condarc <== auto_activate_base: True

On peut l’éditer à la main ou via une commande conda, par exemple :

Commande	Fichier .condarc
conda config --set auto_activate_base false conda config --add channels conda-forge conda config --set channel_priority strict conda config --set auto_update_conda false	auto_activate_base: false channels:   - conda-forge   - defaults auto_update_conda: true channel_priority: strict

Nous pouvons spécifier le ou les canaux (avec une priorité décroissante de gauche à droite) de mise à jour lorsque on installe le paquetage, par exemple pour SciPy :

conda install scipy --channel conda-forge --channel bioconda

Avec le passage sous la distribution miniforge3, l’intérêt de ce fichier diminue dans le sens ou n’utilisons que conda-forge comme canal, en tout cas nous faisons tout pour ne pas mixer avec d’autres canaux quand c’est possible.

3. Vitesse de résolution

Une difficulté souvent évoquée est que conda peut être lent (notamment pour la recherche dans conda-forge) si le nombre de paquetage à lister devient grand. Une manière de procéder est de simplifier, avec des environnements dédiés à un projet avec un minimum de dépendances, ce qui n’est pas toujours possible. Conda est scripté, mamba est une implémentation C/C++ plus rapide, c’est pour cela qu’on l’utilise pour les paquetages.

conda update -n base conda conda install -n base conda-libmamba-solver conda config --set solver libmamba

A noter : le téléchargement/extraction des paquetages sont parallélisés pour gagner sur ce point.