Re: [galaxy-dev] Questions about tool wrapping

[Jeremy Goecks]

> 
> Hmmm, ok. That explains why there are so few uses of it.
> May I suggest amending 
> 
> 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.
___
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:

  http://lists.bx.psu.edu/

Re: [galaxy-dev] Questions about tool wrapping

[Jean-Frédéric Berthelot]

> >> Unfortunately, I can't help much with refresh_on_change either, we just
> >> use the / 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 

to make it clearer that tool developers are not meant to use it?

> >> Regarding the command line: you can have different commandlines,
> >> eg
> >> 
> >>   
> >> #if   ($summary.mode=="a")#commandline1
> >> #elif ($summary.mode=="b")#commandline2
> >> #elif ($summary.mode=="c")#commandline3
> >> #end if
> >>   
> >> 
> >> 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 
 tag.

Thanks,

Jean-Frédéric

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

  http://lists.bx.psu.edu/

Re: [galaxy-dev] Questions about tool wrapping

[Jeremy Goecks]

>> Unfortunately, I can't help much with refresh_on_change either, we just
>> use the / 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
>> 
>>   
>> #if   ($summary.mode=="a")#commandline1
>> #elif ($summary.mode=="b")#commandline2
>> #elif ($summary.mode=="c")#commandline3
>> #end if
>>   
>> 
>> 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.


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

  http://lists.bx.psu.edu/

Re: [galaxy-dev] Questions about tool wrapping

[Jean-Frédéric Berthelot]

> Unfortunately, I can't help much with refresh_on_change either, we just
> use the / 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
> 
>
>  #if   ($summary.mode=="a")#commandline1
>  #elif ($summary.mode=="b")#commandline2
>  #elif ($summary.mode=="c")#commandline3
>  #end if
>
> 
> 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

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

  http://lists.bx.psu.edu/

Re: [galaxy-dev] Questions about tool wrapping

[Hans-Rudolf Hotz]

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:
/
tag sets,  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  (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 , right? But the 
 tag is deprecated, and the doc is unclear about the replacement to use.  seems to 
only work for  data, right?

Also, I am directly calling the binary in the . 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 / 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

  
#if   ($summary.mode=="a")#commandline1
#elif ($summary.mode=="b")#commandline2
#elif ($summary.mode=="c")#commandline3
#end if
  

and one of those 'commandlines' could be two commands (ie indexing 
first, followed by the next binary)



Regards, Hans-Rudolf


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

 http://lists.bx.psu.edu/

Re: [galaxy-dev] Questions about tool wrapping

[Jean-Frédéric Berthelot]

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:
> /
> tag sets,  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  
(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 , right? But the  
tag is deprecated, and the doc is unclear about the replacement to use. 
 seems to only work for  data, right?

Also, I am directly calling the binary in the . 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  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

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

  http://lists.bx.psu.edu/

Re: [galaxy-dev] Questions about tool wrapping

[Hans-Rudolf Hotz]

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: / 
tag sets,  tag set or possibilities with the "refresh_on_change" 
option.





== Error handling ==

I have been trying to use  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  :
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  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 tag, I was hoping to do
something like :

 
 
 Option A
 Option B
 
 
[…]
  
 
 
 
 
 
 
 
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 , but that does not seem to work either




I hope this helps

Regards, Hans-Rudolf





Thanks for your help!

[1] 
--
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:

   http://lists.bx.psu.edu/


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

 http://lists.bx.psu.edu/

[galaxy-dev] Questions about tool wrapping

[Jean-Frédéric Berthelot]

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  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  : 
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  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 tag, I was hoping to do something like 
: 

 
 
Option A 
Option B 
 
 
[…] 
 
 
 
 
 
 
 
 
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 , 
but that does not seem to work either 


Thanks for your help! 

[1]  

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

  http://lists.bx.psu.edu/