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