Depuis la mi-2024 il semble que nous n’ayons plus le droit d’utiliser les paquetages issus de certains canaux d’Anaconda, car les conditions d’utilisation (ToS) ont évolué. Par mesure de précaution il faut modifier les procédures d’installation et s’assurer qu’elles sont bien conformes à la politique de l’établissement si on évolue dans un environnement professionnel.

Article mis à jour en Mai 2026.

1. Définition du problème

Le problème vient d’un point des ToS (Terms of Service) d’Anaconda qui porte sur les conditions d’utilisation par une organisation. Au delà de 200 employés ou sous-traitants, l’utilisation d’Anaconda est considérée comme une utilisation organisationnelle. Les organisations gouvernementales ou à buts non lucratifs sont incluses dans cette définition. Les entités éducatives ne peuvent l’utiliser que pour des cours, ce qui exclue le travail scientifique en laboratoire. Je ne comprends pas très bien si les ToS ne concernent que des distributions professionnelles/enterprise, mais les conditions couvrant Miniconda sont plus éclairantes: l’utilisation de Miniconda pour extraire des mises à jour des packages de certains canaux Conda constitue une violation des conditions de services.

Alors quels sont ces canaux ? Il faut éviter les canaux sous licence: anaconda, anaconda-extras, defaults (main, r et msys2). Dans l’installation de l’environnement (base) nous utilisions préférentiellement le canal defaults qu’il va falloir abandonner au profit de conda-forge, qui était réservé aux paquetages aux environnement de production.
Coté distribution, Miniconda reste libre d’utilisation, mais son installation doit être revue pour bloquer le canal defaults. Une autre possibilité est d’utiliser Miniforge (qui inclue conda et mamba) et qui utilise le canal conda-forge par défaut. Mamba est un gestionnaire de paquet rapide (implémenté en C/C++) qui utilise la même syntaxe que conda (implémenté en Python).

2. Reconfigurer une installation de Miniconda

La première étape est de vérifier les canaux avec une commande conda config, puis d’enlever les canaux defaults, et de vérifier ce qui s’est passé avec une nouvelle commande conda config:

conda config --show channels conda config --remove channels defaults conda config --show channels

Une autre manière de savoir ce qui se passe est de réaliser un export, comme si on allait partager l’environnement, par exemple:

conda env export > env_base.yml conda env export --from-history > env_base.yml conda env export --no-builds > env_base.yml

Normalement dans la section channels: il ne doit y avoir que conda-forge (et d’autres environnements qui ne sont pas sous licence comme bioconda). Il est utile aussi de vérifier le fichier .condarc qui peut encore contenir un appel vers d’autres canaux alternatifs (s’il ne trouvait pas conda-forge) ce qui laisse un risque de violation de licence.
D’une manière complémentaire, on peut bloquer des adresses sur le réseau, soit au niveau du poste (Firewall Windows ou UFW Linux), soit au niveau du firewall. Il s’agit des URLs en [ https://repo.anaconda.com ] et [ https://conda.anaconda.org ]. Sauf que certains canaux peuvent être hébergés via anaconda.org. Il faut donc descendre les localisation des dépôts /pkgs/main/, /pkgs/r/ … La liste est disponible sur plusieurs sites, incluant [ https://docs.anaconda.com/working-with-conda/reference/default-repositories/ ] et celui de l’IRD (cf. liens et lectures).
Il faut également faire attention lors de l’installation des paquets, en spécifiant systématiquement le canal source dans la commande, par exemple :

conda install --channel conda-forge nom_du_paquet conda install -c bioconda nom_du_paquet

3. Application (mise en conformité)

Maintenant il faut tester tout cela, voyons par nous mêmes sur l’environnement (base) :

(base) C:\Dev>conda config --show channels channels: - defaults(base) C:\Dev>conda config --remove channels defaults (base) C:\Dev>conda config --add channels conda-forge (base) C:\Dev>conda config --show channels channels: - conda-forge(base) C:\Dev>cat C:\Users\utilisateur\.condarc channels: - conda-forge

Jusqu’ici tout va bien, voyons avec le fichier YAML :

(base) C:\Dev>conda env export > env_base.yml (base) C:\Dev>cat env_base.yml name: base channels: - defaults - conda-forge dependencies: - anaconda-anon-usage=0.4.4=py310hfc23b7f_100 - archspec=0.2.3=pyhd3eb1b0_0 - asttokens=2.0.5=pyhd3eb1b0_0 ... - zlib=1.2.13=h8cc25b3_1 - zstandard=0.23.0=py310h4fc1ca9_0 - zstd=1.5.6=h8880b57_0 prefix: C:\Python3

Le canal defaults est toujours présent, ce qui se confirme avec un update (interrompu) :

(base) C:\Dev>conda update -n base -c conda-forge conda Retrieving notices: ...working... done Channels: - conda-forge - defaults Platform: win-64 Collecting package metadata ...

On peut essayer conda config --add channels nodefaults qui ne changera rien, nous avons defaults, nodefaults, conda-forge dans le fichier YAML et defaults à l’update. Explication, le canal defaults est codé en dur, mais nous avons la possibilité d’utiliser l’option  --override-channels, par exemple :

C’est très bien, mais nous voyons que le canal conda-forge s’applique aux mises à jour de paquets qui concernent conda, mais qu’il ne remplace pas les autres paquets existants. Dans ce cas, il faut utiliser l’option --all :

conda update --override-channels -n base -c conda-forge --all

Et la ça va faire mal, en extrait :

L’installation fonctionne, mais n’est plus la même, des versions de paquetages peuvent être différentes. Pour valider l’installation, il faut aussi faire la mise à jour sur l’environnement (prod) de manière à voir s’il y a des incohérences et des dépendances non résolues.

(prod) C:\Dev>conda config --set channel_priority (prod) C:\Dev>conda config --show channels channels: - nodefaults - conda-forge

Donc, il n’y a rien de spécial à faire avant de lancer l’update sur tous les paquets.

(prod) C:\Dev>conda update --override-channels -n prod -c conda-forge --all

Globalement, il n’y a pas d’erreurs, il faut donc sauver les profils de paquetages qui caractérisent les environnements. Ce qui peut être fait avec les scripts install-base.bat et install-prod.bat en spécifiant un fichier de spécification (specfile) et non une nouvelle installation. Il faut aussi valider les paquetages avec la suite de tests de manière à finaliser.

Au final, c’est  une méthode qui marche si on veut rapidement se mettre en conformité en gardant une installation existante qui était déjà en partie validée sous conda-forge.

L’autre possibilité (préférée) étant de travailler à partir d’une installation basée sur Miniforge.