Bonjour,
Nous avons fait une mise à jour majeure des applications dans met4j-galaxy : la plupart ont été renommées et d'autres ont fait leur apparition.
Dans Met4j : bugs pendant le lancement, vous aviez fait une merge request pour mettre à jour la liste des applications. J'ai voulu faire la meme chose, j'ai cloné le projet infrastructure mais je ne trouve pas le fichier production/files/dynamic_rules/tool_destinations.yaml que vous aviez modifié.
Est ce que vous pouvez m'aider s'il vous plait ?
Bonne journée,
Ludo Cottret
Merci Thomas mais je ne comprends pas très bien : ce fichier n'est pas l'équivalent de celui que tu avais transformé la dernière fois : la liste des apps met4j n'y figure pas. A moins qu'il n'y en ait plus besoin maintenant ?
Ludo
Salut !
Il y a aussi un autre probleme : toutes les méthodes renommées apparaissent toujours dans la liste sur usegalaxy.fr (avec l'ancien numéro de version). Comment faire pour les enlever ?
Bonne journée,
Ludo
Salut
Je n'ai pas compris ce que tu voulais dire.
Tu peux me fournir un exemple stp
Thomas
Bonjour Thomas,
Pour être plus précis, par exemple l'app SbmlSetRefsFromFile a été renommée en SetReferences. Or, SbmlSetRefsFromFile apparait toujours dans la liste des apps, mais fait partie de la version 1.5.0 alors que la derniere version de met4j est la 2.0.0 (et depuis hier 2.0.1 plus exactement). En fait, il faudrait prendre systématiquement les apps Met4J qui appartiennent à la dernière version. Je ne sais pas si j'ai été plus clair du coup :-). On peut peut etre voir lundi prochain si ça rendre dans l'ordre avec la derniere version 2.0.1...
Ludo
Bonjour @Ludo_Cottret,
Renommer un outil peut toujours poser problème, car cela entraîne des incohérences dans l’affichage et la gestion des versions, comme c'est le cas ici avec SbmlSetRefsFromFile et SetReferences. Pour éviter ces situations, il est généralement préférable de conserver le même nom et de gérer les évolutions via les versions des outils.
Pour régler le souci actuel, on peut :
Bonjour Thomas,
Merci pour ta réponse mais je ne vois pas comment faire malgré les liens que tu m'as envoyé. En effet, ces solutions fonctionnent si chaque app a un depot toolshed différent. Là, pour met4j, toutes les apps sont dans un seul toolshed et du coup, j'ai l'impression que les solutions que tu proposes ne me semblent pas adaptées.
Est ce qu'il est possible d'indiquer dans un fichier de configuration qu'il ne faut faire apparaitre que les apps de la derniere version de met4j ? Un peu comme dans l'exemple du panel pour frogs mais pour un seul toolshed qui contiendrait plusieurs apps ?
Ludo
Bonjour,
Bon, j'ai l'impression qu'on est dans une impasse 
.
Ce qu'on va essayer de faire, c'est de faire un repo et donc un toolshed par app met4j. Ca va nous demander du travail mais peut etre que la gestion va etre simplifiée ensuite. On va en profiter pour passer par conda plutot que singularity.
Par contre, on aura surement besoin d'un peu d'accompagnement :-). Par exemple, comment on spécifie quels toolsheds doivent etre pris en compte dans la section met4j ?
On peut aussi se prévoir une visio, ce serait peut etre plus simple...
Bonne journée,
Ludo
Bonjour,
Nous avons quasiment terminé le split de toutes les apps de met4j dans différents dépôts toolsheds (tests sur le toolshed test de galaxy). Et c'est maintenant conda qui est appelé et plus singularity.
Quelle est la marche à suivre pour la suite ? Quels sont les fichiers à modifier dans infrastructure ?
Bon apres-midi,
Ludo