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