Bonjour à tous,
Pour notre instance locale de Galaxy, nous souhaitions que nos utilisateurs puissent choisir l'emplacement ou écrire leurs résultats et cela sans "casser" les liens dans la base de donnée.
Pour cela, nous avons ainsi mis en place une modification simple du xml des outils existants:
Prenons l'exemple d'un outil simple dont le xml serait le suivant:
<tool id="example" name="Tool example"> <description>Un exemple d'outil simple</description> <command interpreter="bash">example.sh -i $input -o $output</command> <inputs> <param name="input" type="text" label="Input"/> </inputs> <outputs> <data format="txt" name="output" label="outputExample"/> </ouputs> </tool>
Dans cet exemple, le fichier de sortie portera le nom "dataset_xxx" et sera écrit dans le répertoire par défaut <INSTALL_GALAXY>/galaxy-dist/database/files/000/
La modification que nous allons apporter maintenant va nous permettre de définir le répertoire d'écriture de l'output ainsi que le nom du fichier.
Après modification, le xml ressemble à ça:
<tool id="example" name="Tool example"> <description>Un exemple d'outil simple</description> <command interpreter="bash">example.sh -i $input -o $output;mv $output $output_dir/${file_name}.txt 2>/dev/null;ln -s $output_dir/${file_name}.txt $output</command> <inputs> <param name="input" type="text" label="Input"/>
<!-- Output directory-->
<param name="file_name" type="text" size="150" label="File name (without extension)"> <validator type="empty_field" message="You must specify a file name"/> </param> <param name="output_dir" type="text" size="150" label="Output directory"> <validator type="empty_field" message="You must specify an output path"/> </param>
<!---->
</inputs> <outputs> <data format="txt" name="output" label="outputExample"/> </ouputs> </tool>
Nous avons 2 champs input pour le path et le nom du fichier de sortie (ainsi que les valideurs associés, l'outil ne s'execute pas si l'un de ces champs est vide). Puis dans la balise <command> , nous avons ajouter:
mv $output $output_dir/${file_name}.txt 2>/dev/null;ln -s $output_dir/${file_name}.txt $output
qui correpond à un move de <INSTALL_GALAXY>/galaxy-dist/database/files/000/dataset_xxx vers <OUTPUT_CHOISIT>/<NOM_DE_FICHIER_CHOISIT>, suivit de la création d'un lien symbolique <INSTALL_GALAXY>/galaxy-dist/database/files/000/dataset_xxx qui pointe vers <OUTPUT_CHOISIT>/<NOM_DE_FICHIER_CHOISIT>.
Cette modification fonctionne très bien quelque soit l'interpreteur défini dans la balise <command>, et est surtout très rapide à mettre en place.
Je suis très interressé de savoir si d'autres personnes ont implémentés une solution pour le choix du répertoire de sortie, et si oui de quelle manière?
Bonne journée à tous,
Alban
Bonjour Alban,
Merci pour le Tip ! Je suis passé rapidement dans le code et j'ai peut être raté quelque chose mais:
- Quand tu fais ton mv, je ne vois pas la création du directory. Il faut le créer pour l'utilisateur préalablement ou ça se fait tout seul ?
- Est ce qu'il n'y a pas un risque que les utilisateurs s'écrasent mutuellement leur liens symboliques et s'emmêlent les pinceaux si ils utilisent les mêmes paths ?
Clairement c'est très intéressant de pouvoir renommer les fichiers de datasets pour faciliter la relecture des analyses (history). Je n'ai pas essayé, mais est ce que la modif se répercute dans les fenêtres (info) (parent file etc...). ? Ca, ça serait vraiment génial. Encore plus si le nom choisi se répercute dans l'history sur le nom du dataset (au lieu d'avoir le nom de l'outil sur le dataset xx). En fait c'est surtout ça qui m'intéresse - il y a peut être une approche différente sur ce problème.
Par contre, je ne vois pas trop l'intérêt de créer des dossiers personnels qui créent une structuration qui fait doublon avec la base de donnée de galaxy. Ca me parait même générateur de boxon non ?
Chris
Le 12 sept. 2012 à 12:03, Alban Lermine alermine@curie.fr a écrit :
Bonjour à tous,
Pour notre instance locale de Galaxy, nous souhaitions que nos utilisateurs puissent choisir l'emplacement ou écrire leurs résultats et cela sans "casser" les liens dans la base de donnée.
Pour cela, nous avons ainsi mis en place une modification simple du xml des outils existants:
Prenons l'exemple d'un outil simple dont le xml serait le suivant:
<tool id="example" name="Tool example"> <description>Un exemple d'outil simple</description> <command interpreter="bash">example.sh -i $input -o $output</command> <inputs> <param name="input" type="text" label="Input"/> </inputs> <outputs> <data format="txt" name="output" label="outputExample"/> </ouputs> </tool>
Dans cet exemple, le fichier de sortie portera le nom "dataset_xxx" et sera écrit dans le répertoire par défaut <INSTALL_GALAXY>/galaxy-dist/database/files/000/
La modification que nous allons apporter maintenant va nous permettre de définir le répertoire d'écriture de l'output ainsi que le nom du fichier.
Après modification, le xml ressemble à ça:
<tool id="example" name="Tool example"> <description>Un exemple d'outil simple</description> <command interpreter="bash">example.sh -i $input -o $output;mv $output $output_dir/${file_name}.txt 2>/dev/null;ln -s $output_dir/${file_name}.txt $output</command> <inputs> <param name="input" type="text" label="Input"/>
<!-- Output directory-->
<param name="file_name" type="text" size="150" label="File name (without extension)"> <validator type="empty_field" message="You must specify a file name"/> </param> <param name="output_dir" type="text" size="150" label="Output directory"> <validator type="empty_field" message="You must specify an output path"/> </param>
<!---->
</inputs> <outputs> <data format="txt" name="output" label="outputExample"/> </ouputs> </tool>
Nous avons 2 champs input pour le path et le nom du fichier de sortie (ainsi que les valideurs associés, l'outil ne s'execute pas si l'un de ces champs est vide). Puis dans la balise <command> , nous avons ajouter:
mv $output $output_dir/${file_name}.txt 2>/dev/null;ln -s $output_dir/${file_name}.txt $output
qui correpond à un move de <INSTALL_GALAXY>/galaxy-dist/database/files/000/dataset_xxx vers <OUTPUT_CHOISIT>/<NOM_DE_FICHIER_CHOISIT>, suivit de la création d'un lien symbolique <INSTALL_GALAXY>/galaxy-dist/database/files/000/dataset_xxx qui pointe vers <OUTPUT_CHOISIT>/<NOM_DE_FICHIER_CHOISIT>.
Cette modification fonctionne très bien quelque soit l'interpreteur défini dans la balise <command>, et est surtout très rapide à mettre en place.
Je suis très interressé de savoir si d'autres personnes ont implémentés une solution pour le choix du répertoire de sortie, et si oui de quelle manière?
Bonne journée à tous,
Alban
--
Alban Lermine Unité 900 : Inserm - Mines ParisTech - Institut Curie « Bioinformatics and Computational Systems Biology of Cancer » 11-13 rue Pierre et Marie Curie (1er étage) - 75005 Paris - France Tel : +33 (0) 1 56 24 69 84
Galaxy-France mailing list Galaxy-France@lists.bx.psu.edu http://lists.bx.psu.edu/listinfo/galaxy-france
--- Christophe Antoniewski
Drosophila Genetics and Epigenetics Laboratoire de Biologie du Développement – UMR7622 CNRS – Université Pierre & Marie Curie 5ème étage - pièce 517 Case 24, 9 quai Saint Bernard 75252 Paris cedex 05 France
Phone: +33 1 44 27 34 39 Fax: +33 1 44 27 34 45 Mobile: +33 6 68 60 51 50 web site http://drosophile.org
Salut Christophe,
Pour répondre à tes questions:
- Quand tu fais ton mv, je ne vois pas la création du directory. Il
faut le créer pour l'utilisateur préalablement ou ça se fait tout seul ?
Le répertoire doit être créé au préalable sur le serveur, ce qui doit se faire en dehors de Galaxy. Je pense qu'il serait possible de gérer la création de répertoire en utilisant la ligne suivante:
<command interpreter="bash">example.sh -i $input -o $output; #if ! -e $output_dir: mkdir $output_dir #end if; mv $output $output_dir/${file_name}.txt 2>/dev/null;ln -s $output_dir/${file_name}.txt $output</command>
On ajoute donc #if ! -e $output_dir: mkdir $output_dir #end if; (ou quelque chose approchant), qui nous permet de tester l'existence du répertoire et le cas échéant de le créer.
- Est ce qu'il n'y a pas un risque que les utilisateurs s'écrasent
mutuellement leur liens symboliques et s'emmêlent les pinceaux si ils utilisent les mêmes paths ?
Effectivement, si un utilisateur utilise le même path et le même nom de fichier que pour une analyse précédente, il va écraser le fichier existant (ce qui reste parfaitement logique). Par contre les liens symboliques ne peuvent pas être écraser puisque l'on réutilise l'identifiant unique dataset_xxx créer par Galaxy. Donc dans le cas cité plus tôt, on va créer deux liens symboliques pointant vers le même fichier.
Clairement c'est très intéressant de pouvoir renommer les fichiers de datasets pour faciliter la relecture des analyses (history). Je n'ai pas essayé, mais est ce que la modif se répercute dans les fenêtres (info) (parent file etc...). ? Ca, ça serait vraiment génial. Encore plus si le nom choisi se répercute dans l'history sur le nom du dataset (au lieu d'avoir le nom de l'outil sur le dataset xx). En fait c'est surtout ça qui m'intéresse - il y a peut être une approche différente sur ce problème.
Le lien symbolique ne sera pas indiqué dans les infos du dataset comme c'est le cas pour un dataset créé via les librairies avec utilisation des liens symboliques (ça doit être possible en modifiant à la volée les infos sur le dataset, mais je ne me suis pas penché la dessus). Par contre, pour ce qui est du nom du dataset dans l'historique et les infos, une façon très simple d'attribuer le nom de fichier donné par l'uitlisateur est la suivante:
<!-- Output directory-->
<param name="file_name" type="text" size="150" label="File name (without extension)"> <validator type="empty_field" message="You must specify a file name"/> </param> <param name="output_dir" type="text" size="150" label="Output directory"> <validator type="empty_field" message="You must specify an output path"/> </param>
<!---->
</inputs> <outputs>
<!-- Attribution d'un label "parlant" à notre output-->
<data format="txt" name="output" label="${file_name}"/> </ouputs>
Ici, on attribue à notre output un label correspondant au nom de fichier donné par l'utilisateur en utilisant la variable ${file_name} (ce qui permet d'un peu plus s'y retrouvé dans l'historique).
Par contre, je ne vois pas trop l'intérêt de créer des dossiers personnels qui créent une structuration qui fait doublon avec la base de donnée de galaxy. Ca me parait même générateur de boxon non ?
L'idée chez nous n'était pas de créer des dossiers personnels de travail, mais de faire fitter Galaxy sur l'arborescence projet structurée déja en place. De cette façon, nos données sont correctement rangées dans les diférents répertoires projets sans perdre la structuration des données en historique au niveau de Galaxy. Un autre avantage est que l'on peut découpler le stockage des données du serveur web faisant tourner Galaxy puisque le répertoire database de Galaxy ne va finalement contenir que des liens symboliques.
On se retrouve en effet avec deux niveaux de structuration, mais comme le niveau Galaxy est parfaitement gérer par l'appli elle même..
Par contre, je conseillerais d'utiliser ce genre de tip sur une instance de Galaxy ou les jobs sont lancés "en tant que l'utilisateur courant", sinon, si le user applicatif du serveur web est toujours le même (par défaut) et qu'il possède plus de droits qu'un utilisateur Lambda, il devient difficile de contrôler les écritures et n'importe qui peut écrire n'importe où du moment que le user applicatif a les droits.
D'ailleurs, lancer des jobs dans Galaxy en tant que l'utilisateur courant sera certainement l'objet de mon prochain mail sur la liste. J'ai déja une solution à proposer (en place chez nous et parfaitement fonctionnelle), mais elle est quelque peu brutale.. J'espère donc que d'autres personnes auront trouvé des solutions plus "propre" qu'ils pourront nous exposer..
++,
Alban
Le 12 sept. 2012 à 15:36, Alban Lermine alermine@curie.fr a écrit :
<!-- Attribution d'un label "parlant" à notre output-->
<data format="txt" name="output" label="${file_name}"/> </ouputs>
Super, ça s'éloigne du sujet initial mais je trouve que ça va bien aider à s'y retrouver dans les histoires. Next step : faire qu'un label soit passé de job en job dans un workflow ... ;-) afin de visualiser plus facilement les résultats de ce workflow (une sorte de préfix qui se rajouterait sur tous les labels de datasets générés par un workflow - sans avoir à éditer le workflow complet à chaque fois évidement !)
Chris --- Christophe Antoniewski
Drosophila Genetics and Epigenetics Laboratoire de Biologie du Développement – UMR7622 CNRS – Université Pierre & Marie Curie 5ème étage - pièce 517 Case 24, 9 quai Saint Bernard 75252 Paris cedex 05 France
Phone: +33 1 44 27 34 39 Fax: +33 1 44 27 34 45 Mobile: +33 6 68 60 51 50 web site http://drosophile.org
galaxy-france@lists.galaxyproject.org
-
Alban Lermine -
Christophe Antoniewski