JupyterLab : setup Data Science propre (conda/pip, kernels, images Docker)

Quand on utilise JupyterLab au quotidien, le problème n°1 arrive vite : les dépendances se mélangent. Un carnet marche aujourd’hui, casse demain, ou refuse d’importer un module alors qu’il “est installé”.

L’objectif d’un setup propre est simple : un environnement stable pour l’interface JupyterLab + un environnement par projet pour l’exécution (kernel).

Si vous partez de zéro, commencez par ce guide : Déployer JupyterLab en production (HTTPS, auth, persistance).

La règle d’or : 1 projet = 1 environnement

Un environnement unique “base” finit presque toujours en conflit : versions incompatibles, dépendances transitoires, carnet qui ne se relance plus, etc.

À la place :

• 1 environnement “jupyterlab” (UI + extensions)
• 1 environnement par projet : projet-a, projet-b, …

Sur adgents.cloud, cette séparation est particulièrement pratique car vous pouvez dimensionner CPU/RAM selon le besoin, et stop/start l’instance quand vous ne travaillez pas (le compute n’est pas facturé à l’arrêt).

Lien utile : JupyterLab : sécurité (RBAC, tokens, reverse proxy).

Option A (simple et robuste) : ipykernel par environnement

Le principe : vous installez vos libs dans un environnement conda dédié, puis vous enregistrez cet environnement comme kernel.

Exemple : créer un env projet + kernel

# 1) créer l’environnement
conda create -n projet-a python=3.11 -y
conda activate projet-a

# 2) installer vos dépendances
conda install -y numpy pandas
python -m pip install scikit-learn

# 3) ajouter le kernel Jupyter
conda install -y ipykernel
python -m ipykernel install --user --name projet-a --display-name "Python (projet-a)"

Dans JupyterLab, vous pourrez ensuite choisir Python (projet-a) comme kernel.

Détail technique (référence) : la doc IPython explique le fonctionnement de ipykernel install et l’intérêt des noms distincts : https://ipython.readthedocs.io/en/stable/install/kernel_install.html

Bonnes pratiques de nommage

• --name : court, sans espaces, stable
• --display-name : lisible pour l’équipe (inclure le projet et, si besoin, la version Python)

Option B (pratique quand on a beaucoup d’environnements) : nb_conda_kernels

Si vous gérez de nombreux environnements, nb_conda_kernels peut détecter automatiquement les environnements conda qui contiennent un kernel compatible (ex. ipykernel).

En résumé :

• installez nb_conda_kernels dans l’environnement où vous lancez JupyterLab
• installez ipykernel dans chaque environnement projet

Référence : https://github.com/anaconda/nb_conda_kernels

Conda vs pip : comment choisir sans se piéger

Une règle pragmatique :

• conda pour les dépendances “lourdes” (BLAS, numpy/scipy, libs compilées)
• pip pour les paquets qui évoluent vite ou qui ne sont pas disponibles proprement en conda

Conservez la cohérence : évitez de mélanger au hasard dans le même env.

Rendre le projet relançable : figer les dépendances

L’erreur fréquente est de “juste installer” des libs, puis d’oublier comment reconstruire l’environnement.

Si vous êtes 100% conda

• exportez un fichier environment.yml

conda env export -n projet-a > environment.yml

Si vous mélangez conda + pip

• gardez un environment.yml (conda)
• gardez un requirements.txt (pip)

Puis un script de rebuild :

conda env create -f environment.yml
conda activate projet-a
python -m pip install -r requirements.txt

Pour comprendre clairement la différence entre écosystèmes conda/pip et l’intérêt des environnements isolés : https://ubc-mds.github.io/DSCI_521_platforms-dsci_book/lectures/7a-virtual-environments-conda.html

Quand passer à une image Docker dédiée

Dès que vous avez :

• des dépendances système (ex. ffmpeg, libgeos, drivers, outils CLI)
• des extensions JupyterLab spécifiques
• un besoin de reproductibilité “à l’identique”

… une image Docker dédiée devient le meilleur levier.

Approche recommandée :

1. image “jupyterlab” stable (UI)
2. environnements projet dans l’image ou reconstruits au démarrage
3. stockage persistant pour vos carnet et datasets

Vidéo (FR) : environnement conda + Jupyter

En résumé (plan d’action)

1. Gardez un env “jupyterlab” stable
2. Créez 1 env conda par projet
3. Enregistrez un kernel par env (ou utilisez nb_conda_kernels)
4. Figez vos dépendances (environment.yml / requirements.txt)
5. Si ça devient complexe, passez à une image Docker dédiée

Si vous voulez héberger JupyterLab en production (HTTPS, persistance, backups automatiques, stop/start), testez : https://www.adgents.cloud/applications/jupyterlab