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
--
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