Hi list, I am currently writing a Galaxy wrapper (for SortMeRNA [1]) and I would have several questions. == Pre-processing an input == SortMeRNA filters rRNA reads against an indexed rRNA database. This database can either be one bundled together with SortMeRNA and defined in a relevant .loc file, or one from the history. Either way, it must have been processed beforehand with another binary (just like makeblastdb/blastp). I am not sure of the best design here. * Providing another wrapper for this other binary, with users explicitly using it beforehand in their workflow? *Assuming the databases have been processed outside of Galaxy beforehand ? (As the tool relies on the file name, this would work for databases in the .loc file but not ones from the history) *Providing an extra-smart wrapper which would check if the database has been indexed, and if not invisibly indexing before running SortMeRNA ? == Error handling == I have been trying to use <stdio><regex> to catch an error (the one defined in above section actually) and inform the user with a meaningful message. >From the console debug, it seems the error is correctly detected, since it displays the custom <regex description=""> : galaxy.jobs INFO 2013-01-22 19:02:04,198 Job 202: Fatal error: The database ${databases} has not been preprocessed using buildtrie before using SortMeRNA. But Galaxy only displays in the failed history a generic message « tool error An error occurred running this job: Unable to finish job » Am I missing something, or the <stdio><regex> is not meant to be used this way? == Using a previously set choice to set a default value later == Main option Alpha (a binary choice A/B) influence the default value of advanced option Beta (a float). Beta is buried into the "advanced options" section − I’d rather not have it just next to Alpha. Mirroring constructs seen in the <action>tag, I was hoping to do something like : <conditional name="Alpha"> <param name="Alpha_selector" type="select" format="text"> <option value="A">Option A</option> <option value="B">Option B</option> </param> </conditional> […] <conditional name="Alpha.Alpha_selector"> <when value="A"> <param name="Beta" type="float" value="0.15"/> </when> <when value="B"> <param name="Beta" type="float" value="0.25"/> </when> </conditional> But that does not seem to work. Am I missing something, or is it just not possible ? Alternatively, I looked into setting some hidden variable $default_value in the Alpha select, which would be used as <param name="Beta" value=$default_value/>, but that does not seem to work either Thanks for your help! [1] <http://bioinfo.lifl.fr/RNA/sortmerna/> -- Jean-Frédéric Bonsai Bioinformatics group
Hi Jean-Frederic
I am currently writing a Galaxy wrapper (for SortMeRNA [1]) and I would have several questions.
== Pre-processing an input ==
SortMeRNA filters rRNA reads against an indexed rRNA database. This database can either be one bundled together with SortMeRNA and defined in a relevant .loc file, or one from the history. Either way, it must have been processed beforehand with another binary (just like makeblastdb/blastp).
I am not sure of the best design here. *Providing another wrapperfor this other binary, with users explicitly using it beforehand in their workflow? *Assuming the databases have been processed outside of Galaxy beforehand ? (As the tool relies on the file name, this would work for databases in the .loc file but not ones from the history) *Providing an extra-smart wrapper which would check if the database has been indexed, and if not invisibly indexing before running SortMeRNA ?
or providing an extra-flexible wrapper (and its corresponding UI defined in the XML file): You first ask the question whether the database is in the history (indexed or to be indexed) or in the local files system. Then depending on the choice, the UI changes according the three options. There are several ways to offer a dynamic UI, eg: <conditional>/<when> tag sets, <page> tag set or possibilities with the "refresh_on_change" option.
== Error handling ==
I have been trying to use <stdio><regex> to catch an error (the one defined in above section actually) and inform the user with a meaningful message. From the console debug, it seems the error is correctly detected, since it displays the custom <regex description=""> : galaxy.jobs INFO 2013-01-22 19:02:04,198 Job 202: Fatal error: The database ${databases} has not been preprocessed using buildtrie before using SortMeRNA. But Galaxy only displays in the failed history a generic message « tool error An error occurred running this job: /Unable to finish job/ »
Am I missing something, or the <stdio><regex> is not meant to be used this way?
You should get the complete error message when you click on the 'bug' icon.
== Using a previously set choice to set a default value later ==
Main option Alpha (a binary choice A/B) influence the default value of advanced option Beta (a float). Beta is buried into the "advanced options" section − I’d rather not have it just next to Alpha.
Mirroring constructs seen in the <action>tag, I was hoping to do something like :
<conditional name="Alpha"> <param name="Alpha_selector" type="select" format="text"> <option value="A">Option A</option> <option value="B">Option B</option> </param> </conditional> […] <conditional name="Alpha.Alpha_selector"> <when value="A"> <param name="Beta" type="float" value="0.15"/> </when> <when value="B"> <param name="Beta" type="float" value="0.25"/> </when> </conditional> But that does not seem to work. Am I missing something, or is it just not possible ?
I don't think this is possible without having it just next to Alpha.
Alternatively, I looked into setting some hidden variable $default_value in the Alpha select, which would be used as <param name="Beta" value=$default_value/>, but that does not seem to work either
I hope this helps Regards, Hans-Rudolf
Thanks for your help!
[1] <http://bioinfo.lifl.fr/RNA/sortmerna/> -- Jean-Frédéric Bonsai Bioinformatics group
___________________________________________________________ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at:
Hi Hans-Rudolf, Thank you for your answer.
I am not sure of the best design here. *Providing another wrapperfor this other binary, with users explicitly using it beforehand in their workflow? *Assuming the databases have been processed outside of Galaxy beforehand ? (As the tool relies on the file name, this would work for databases in the .loc file but not ones from the history) *Providing an extra-smart wrapper which would check if the database has been indexed, and if not invisibly indexing before running SortMeRNA ?
or providing an extra-flexible wrapper (and its corresponding UI defined in the XML file): You first ask the question whether the database is in the history (indexed or to be indexed) or in the local files system. Then depending on the choice, the UI changes according the three options. There are several ways to offer a dynamic UI, eg: <conditional>/<when> tag sets, <page> tag set or possibilities with the "refresh_on_change" option.
I see. Actually, I already implemented the UI change to ask whether the database is selected from local file system or history tab, using <conditional> (just like in the fimo.xml wrapper). I am a bit confused about the refresh_on_change, is there any documentation on it? The only working example I see in the tools is the rgManQQ.xml wrapper, where it is used jointly with dynamic_options (same question about doc?). This seems to be handy ; but unless I am mistaken it seems it can only work with a <code>, right? But the <code> tag is deprecated, and the doc is unclear about the replacement to use. <actions> seems to only work for <output> data, right? Also, I am directly calling the binary in the <command>. If I understand you correctly, it would be easier to hae an additional Python wrapper, which would pre-index the database is needed or asked. Is that correct?
Am I missing something, or the <stdio><regex> is not meant to be used this way?
You should get the complete error message when you click on the 'bug' icon.
When clicking on the bug icon, Galaxy tells me “Either this dataset does not exist or you do not have permission to access it.” (but that may be a problem with my local Galaxy instance I guess)
I don't think this is possible without having it just next to Alpha.
I see, thanks.
I hope this helps
It does, thanks! Cheers, -- Jean-Frédéric
On 01/23/2013 12:22 PM, Jean-Frédéric Berthelot wrote:
Hi Hans-Rudolf,
Thank you for your answer.
I am not sure of the best design here. *Providing another wrapperfor this other binary, with users explicitly using it beforehand in their workflow? *Assuming the databases have been processed outside of Galaxy beforehand ? (As the tool relies on the file name, this would work for databases in the .loc file but not ones from the history) *Providing an extra-smart wrapper which would check if the database has been indexed, and if not invisibly indexing before running SortMeRNA ?
or providing an extra-flexible wrapper (and its corresponding UI defined in the XML file): You first ask the question whether the database is in the history (indexed or to be indexed) or in the local files system. Then depending on the choice, the UI changes according the three options. There are several ways to offer a dynamic UI, eg: <conditional>/<when> tag sets, <page> tag set or possibilities with the "refresh_on_change" option.
I see. Actually, I already implemented the UI change to ask whether the database is selected from local file system or history tab, using <conditional> (just like in the fimo.xml wrapper). I am a bit confused about the refresh_on_change, is there any documentation on it? The only working example I see in the tools is the rgManQQ.xml wrapper, where it is used jointly with dynamic_options (same question about doc?). This seems to be handy ; but unless I am mistaken it seems it can only work with a <code>, right? But the <code> tag is deprecated, and the doc is unclear about the replacement to use. <actions> seems to only work for <output> data, right?
Also, I am directly calling the binary in the <command>. If I understand you correctly, it would be easier to hae an additional Python wrapper, which would pre-index the database is needed or asked. Is that correct?
Unfortunately, I can't help much with refresh_on_change either, we just use the <conditional>/<when> tag set. I have been under the impression the the documentation has been written for 'refresh_on_change' in the meantime. I am sorry, I should have checked first, before suggesting it. Regarding the command line: you can have different commandlines, eg <command> #if ($summary.mode=="a")#commandline1 #elif ($summary.mode=="b")#commandline2 #elif ($summary.mode=="c")#commandline3 #end if </command> and one of those 'commandlines' could be two commands (ie indexing first, followed by the next binary) Regards, Hans-Rudolf
Unfortunately, I can't help much with refresh_on_change either, we just use the <conditional>/<when> tag set. I have been under the impression the the documentation has been written for 'refresh_on_change' in the meantime. I am sorry, I should have checked first, before suggesting it.
No problem. I’ll know to keep en eye for documentation on this feature :)
Regarding the command line: you can have different commandlines, eg
<command> #if ($summary.mode=="a")#commandline1 #elif ($summary.mode=="b")#commandline2 #elif ($summary.mode=="c")#commandline3 #end if </command>
and one of those 'commandlines' could be two commands (ie indexing first, followed by the next binary)
I had not thought of that! That makes sense, yes. I’ll do that. Thanks! -- Jean-Frédéric
Unfortunately, I can't help much with refresh_on_change either, we just use the <conditional>/<when> tag set. I have been under the impression the the documentation has been written for 'refresh_on_change' in the meantime. I am sorry, I should have checked first, before suggesting it.
No problem. I’ll know to keep en eye for documentation on this feature :)
refresh_on_change is not a feature that is exposed to tool developers for use in tool wrappers. Instead, it's used behind the scenes to make conditional/when and dynamic options tags work.
Regarding the command line: you can have different commandlines, eg
<command> #if ($summary.mode=="a")#commandline1 #elif ($summary.mode=="b")#commandline2 #elif ($summary.mode=="c")#commandline3 #end if </command>
and one of those 'commandlines' could be two commands (ie indexing first, followed by the next binary)
I had not thought of that! That makes sense, yes. I’ll do that.
Frequently, if/else is used to progressively build a command line: -- my_script.py #if option1: --enable-option1 --option1-parameter $option1-parameter #elif option2: --enable-option1 --option1-parameter $option1-parameter #endif -- Best, J.
Unfortunately, I can't help much with refresh_on_change either, we just use the <conditional>/<when> tag set. I have been under the impression the the documentation has been written for 'refresh_on_change' in the meantime. I am sorry, I should have checked first, before suggesting it.
No problem. I’ll know to keep en eye for documentation on this feature :)
refresh_on_change is not a feature that is exposed to tool developers for use in tool wrappers. Instead, it's used behind the scenes to make conditional/when and dynamic options tags work.
Hmmm, ok. That explains why there are so few uses of it. May I suggest amending <http://wiki.galaxyproject.org/Admin/Tools/ToolConfigSyntax#A.3Cpage.3E_tag_set> to make it clearer that tool developers are not meant to use it?
Regarding the command line: you can have different commandlines, eg
<command> #if ($summary.mode=="a")#commandline1 #elif ($summary.mode=="b")#commandline2 #elif ($summary.mode=="c")#commandline3 #end if </command>
and one of those 'commandlines' could be two commands (ie indexing first, followed by the next binary)
I had not thought of that! That makes sense, yes. I’ll do that.
Frequently, if/else is used to progressively build a command line:
-- my_script.py
#if option1: --enable-option1 --option1-parameter $option1-parameter #elif option2: --enable-option1 --option1-parameter $option1-parameter #endif
Sure. I meant I had not thought of executing *several* commands in the <command> tag. Thanks, Jean-Frédéric
Hmmm, ok. That explains why there are so few uses of it. May I suggest amending <http://wiki.galaxyproject.org/Admin/Tools/ToolConfigSyntax#A.3Cpage.3E_tag_set> to make it clearer that tool developers are not meant to use it?
Done. Please note that it is a wiki, so anyone can make updates. Best, J.
participants (3)
-
Hans-Rudolf Hotz -
Jean-Frédéric Berthelot -
Jeremy Goecks