Bonjour
Chaque mise à jour d'un outils Galaxy apporte son lot de question.
Une des dépendances (R !) ne s'installe plus. Je vais tester d'éventuellement mettre toutes mes dépendances à jour et de vérifier la cohérence des résultats, mais ce travail est long et j'aimerais bien trouvé une solution plus stable dans le temps que de systématiquement tout refaire.
J'ai vu que Galaxy acceptait des biocontainers.
Ma question est simple, est ce que vous pensez que cette façon de résoudre les dépendances va devenir suffisamment populaire (voir standard comme conda), pour que cela vaille le coup de passer du temps à apprendre comment faire.
Ainsi je pourrais créer un container par version de mon outils avec toutes les dépendances, le mettre à jour quand je m'autoriserais de le faire.
Qu'est ce que vous en pensez ?
Maria
Bonjour Maria,
J'ai le sentiment que les containers pour le déploiement ou le partage d'outil est en effet une solution de plus en plus usitée et tout aussi populaire que conda.
Par contre, si cela permets d'enregistrer une image (et ses dépendances) à un instant t, cela ne résout pas en soi les problèmes de dépendances qui ne sont plus disponibles. Si on souhaite maintenir un outil dans le temps, il faudra donc toujours résoudre ces problèmes pour reconstruire une image.
Mais je ne suis pas expert dans tous ça, @team.software @team.galaxy qu'en pensez-vous ?
Salut,
Galaxy utilise pas mal les containers docker/singularity générés automatiquement au moment de la publication des paquets conda (Index of /singularity/). Ça a l'avantage de figer l'image au moment où le paquet conda fonctionne (puisqu'une install conda peut toujours foirer plus tard s'il y a des changements au niveau des dépendances).
Quand on besoin de plusieurs paquets conda, il y a les images mulled qui permettent de faire aussi des images figées. Elles sont générées automatiquement quand on dépose son outil galaxy sur certains dépôts (genre IUC), mais il y a aussi moyen d'en demander la création sur GitHub - BioContainers/mulled: Mulled - Automatized Containerized Software Repository.
Tout ça est assez à la mode, utilisé en prod et dans les tests automatisés, donc pas trop de risques à l'utiliser. C'est juste une question de config de galaxy pour lui dire d'utiliser conda ou docker ou singularity selon ce dont on a avis.
Il y a aussi moyen de dire qu'un outil doit tourner uniquement avec une image docker ou singularity précise, la plupart du temps non-issue de bioconda, mais c'est moins couramment utilisé (moins flexible pour les admins de serveurs galaxy, et du travail en plus pour créer/maintenir l'image)...
Anthony
1 « J'aime »
Merci pour vos retours.
C'est donc une solution qui pourrait bien se démocratiser et donc est à envisager pour les développeurs d'outils.
Bonne journée
Maria