Perdue dans les modules

J'ai un petit soucis avec le chargement des modules, certaines librairies python ne sont pas disponibles si je charge conda après python (l'inverse fonctionne):

[mhennion @ clust-slurm-client 09:57]$ RASflow : module purge
[mhennion @ clust-slurm-client 10:01]$ RASflow : module load python conda
[mhennion @ clust-slurm-client 10:01]$ RASflow : python
Python 3.7.3 | packaged by conda-forge | (default, Jul  1 2019, 21:52:21) 
[GCC 7.3.0] :: Anaconda, Inc. on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import pandas
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ModuleNotFoundError: No module named 'pandas'
>>> 
[mhennion @ clust-slurm-client 10:01]$ RASflow : module purge
[mhennion @ clust-slurm-client 10:01]$ RASflow : module load conda python
[mhennion @ clust-slurm-client 10:01]$ RASflow : python
Python 3.7.3 | packaged by conda-forge | (default, Jul  1 2019, 21:52:21) 
[GCC 7.3.0] :: Anaconda, Inc. on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import pandas
>>> 

Est-ce qu'il y a des règles à respecter quand on importe plusieurs modules?

Merci de votre aide!!

Par curiosité, pour vouloir importer conda ?

Oui bonne question, ça peut paraître bizarre en effet. En fait j'utilise snakemake --use-conda --drmaa comme dans votre tutorial, les étapes du workflow se déroulent alors dans un environnement conda. Il me faut donc faire un module load conda snakemake slurm-drmaa et pas module load snakemake conda slurm-drmaa pour avoir toutes mes librairies python.

Notre système se veut peu complexe pour l'utilisateur : usage de module pour charger de manière transparente des env Conda et des images Singularity.

Mais il semble perfectible quand en effet on peut "stacker"/empiler plusieurs modules utilisant Python. Les env conda et python viennent avec 2 arborescences python différentes ... donc l'un écrase l'autre.

Nous devrions peut-être surcharger $PYTHONPATH quand on load un env qui tourne autour de Python ?

Nous sommes en effectif restreint et @julien, le grand guru de module est en congés.
Mais peut-être que d'autres membres de la @team.workflow pourrait aider ici ?

L'idée est que snakemake installe des dépendances conda du workflow, c'est ça ?

A mon grand désespoir, je ne pratique pas Snakemake. Mais pour moi, il y a 2 stratégies :

  • On charge toute les dépendances necessaires (via module) avant de lancer Snakemake. Donc pas besoin de --use-conda
  • On laisse Snakemake installer tout le nécessaire via conda. Donc juste besoin de l'env conda.

Note que normalement, drmaa est maintenant compris dans l'env Conda.

Merci de ce retour. C'est bien ça, j'essaie de faire un workflow facilement transportable vers d'autres clusters de calcul (pardon d'envisager cette infidélité!) en laissant snakemake installer le nécessaire via conda. Pour l'instant, ça fonctionne bien en commençant par

module load conda snakemake slurm-drmaa

J'ai fait un test avec seulement :

module load conda snakemake

mais ça ne fonctionne pas (peut-être pour la même raison d'écrasement d'arborescence python?)

Building DAG of jobs...
Exception in thread Thread-1:
Traceback (most recent call last):
  File "/shared/mfs/data/software/miniconda/envs/snakemake-5.19.2/lib/python3.8/threading.py", line 932, in _bootstrap_inner
    self.run()
  File "/shared/mfs/data/software/miniconda/envs/snakemake-5.19.2/lib/python3.8/threading.py", line 870, in run
    self._target(*self._args, **self._kwargs)
  File "/shared/mfs/data/software/miniconda/envs/snakemake-5.19.2/lib/python3.8/site-packages/snakemake/executors/__init__.py", line 1278, in _wait_for_jobs
    import drmaa
  File "/shared/mfs/data/software/miniconda/envs/snakemake-5.19.2/lib/python3.8/site-packages/drmaa/__init__.py", line 65, in <module>
    from .session import JobInfo, JobTemplate, Session
  File "/shared/mfs/data/software/miniconda/envs/snakemake-5.19.2/lib/python3.8/site-packages/drmaa/session.py", line 39, in <module>
    from drmaa.helpers import (adapt_rusage, Attribute, attribute_names_iterator,
  File "/shared/mfs/data/software/miniconda/envs/snakemake-5.19.2/lib/python3.8/site-packages/drmaa/helpers.py", line 36, in <module>
    from drmaa.wrappers import (drmaa_attr_names_t, drmaa_attr_values_t,
  File "/shared/mfs/data/software/miniconda/envs/snakemake-5.19.2/lib/python3.8/site-packages/drmaa/wrappers.py", line 52, in <module>
    raise RuntimeError(('Could not find drmaa library.  Please specify its ' +
RuntimeError: Could not find drmaa library.  Please specify its full path using the environment variable DRMAA_LIBRARY_PATH
WorkflowError:
Error loading drmaa support:
Could not find drmaa library.  Please specify its full path using the environment variable DRMAA_LIBRARY_PATH
  File "/shared/mfs/data/software/miniconda/envs/snakemake-5.19.2/lib/python3.8/site-packages/snakemake/executors/__init__.py", line 1204, in __init__

Bref, j'ai une solution pour l'instant, mais je reste ouverte si quelqu'un a mieux!

Snakemkae charge effectivement lezs modules condas spécifiés soit dans les règles, soit dans un fichier de configuration (yaml par exemple, mais json est aussi supporté d'après mes souvenirs).

Je pense qu'il vaut beaucoup mieux charger d'abord le module conda, et laisser snakemake faire le reste, pous'assurer qu'on a exactement le même traitement quand on fait tourner le workflow sur ifb-core-cluster qu'à un autre endroit.

Il faudrait cependant vérifier les conséquences en terme d'installation de packages conda. Il me semble que snakemake installe localement (dans un dossier .snakemake) les modules dont il a besoin. Ceci signifie qu'il installera automatiquement tous les modules requis par le workflow, même si ces modules sont déjà installés pour tous les usagers. A tester sans doute.

L'erreur est là:

RuntimeError: Could not find drmaa library.  Please specify its full path using the environment variable DRMAA_LIBRARY_PATH

Tente avec ça en amont :

export DRMAA_LIBRARY_PATH=/shared/software/slurm-drmaa/1.0.8/libdrmaa.so.1.0.8