Question: Galaxy wrapper for a tool that takes a configfile.txt
2
gravatar for kramdi.a
4.6 years ago by
kramdi.a40
France
kramdi.a40 wrote:

Hi,

Maybe I'm asking a beginner question, please bear with me. 

I'm currently in charge of the integration of a tool into Galaxy (I am doing it for the first time, with modest programming skills). My tool (coded in C++) takes input files AND a configuration file (configfile.txt) as arguments. It generates 3 output files.

I'm having trouble deciding on a strategy to pass the arguments to my tool. to be exact, I am having trouble creating the configfile.txt needed from the parameters that the user enters, because, in my logic, that's what I should do since the execution of my tool requires this argument. Here's what I am thinking about :

1) In the Galaxy documentation I read about the <configfiles> tags (which I didn't fully understand, mainly because I can't really see how Cheetah works), is this what I need to describe the file? 

2) I could write a shell script that catches the parameters entered in the form, creates the confgfile.txt, calls my program  (with confgfile.txt as one of the arguments) and returns the output of my program.

How should I proceed ? is my logic correct ? (you never know)

Thank you !

 

ADD COMMENTlink modified 4.6 years ago by Dave B.410 • written 4.6 years ago by kramdi.a40
4
gravatar for Dave B.
4.6 years ago by
Dave B.410
United States
Dave B.410 wrote:

Yes, the <configfiles> tag will do exactly what you describe. Take, as an example, a tool that has a field where you can paste a list of read groups to process. In order to get that pasted list into a config file, you would want to use a syntax similar to the following:

<configfile name="read_groups">
#set pasted_data = ''
#if str( $limit.read_groups ) == "paste_list":
    #set pasted_data = $read_groups.pasted_read_groups
#end if
${pasted_data}
</configfile>

And then in your tool's command section, you would add:

<command>tool_binary --configfile ${read_groups} --first_input ${first_input_file} --option1 ${option1}</command>

To populate the read_groups parameter using this example, you would need a conditional and an input parameter defined with the following syntax:

<conditional name="limit">
    <param name="read_groups" type="select" label="Select read groups to process">
        <option value="paste_list" selected="True">Pasted list</option>
        <option value="all">All read groups</option>
    </param>
    <when value="paste_list">
        <param name="pasted_read_groups" type="text" area="true" size="10x35" label="Read groups" help="Paste a list of read groups here, separated by newlines"/>
    </when>
    <when value="all" />
</conditional>

 

ADD COMMENTlink modified 4.6 years ago • written 4.6 years ago by Dave B.410

Thank you for your quick and clear reply. I think my biggest problem is with Cheetah syntax , almost all example wrappers I studied use it, my head is burning with questions as I don't find the documentation very clear. If you could answer some of my basic questions, it would be very kind and helpful.

1) Here are some questions about Cheetah syntax in this context :

a) is $limit.read_groups equivalent to : $limit['read_groups'] ? I can intuitively understand the dotted notation, is it equivalent to the dictionary like notation I encountered ? 

b) I have encountered this notation too : ${X.fields.path }, does it refer to the path of X ?

c) in the command line tag, why put --configfile,  --first_input before the variables ? 

2) what if my configfile.txt has to look like this (example with a tool that takes fragments lengths as parameters) :

minLen 150

maxLen 200

Now, can I transform my parameters into a configfile doing this :

<configfiles>

   <configfile name="tool_config_file">

   min_len ${min_len}

   max_len ${max_len}

   </configfile>

</configfiles>

having descried the parameters in this simple way ;

<param name="min_len" type="integer" value="100" label="Minimum fragment length used"/>

<param name="max_len" type="integer" value="500" label="Maximum fragment length used"/>

 

Thank you !

ADD REPLYlink modified 4.6 years ago by Martin Čech ♦♦ 4.9k • written 4.6 years ago by kramdi.a40
1

1a) No, $limit.read_groups indicates that there is a Parameter object with a read_groups member, and retrieves the string value of that read_groups member. If you think of defined parameters as C structures, rather than arrays, it should make more sense.

1b) Yes, ${option.fields.path} is normally used to indicate a path to the file specified by the option named "option".

1c) I chose that notation to indicate that these are flagged command line options, if your tool uses position to indicate which argv[x] represents which input, you can of course omit those flags.

2) Yes, that syntax looks correct.

ADD REPLYlink written 4.6 years ago by Dave B.410

You have been very helpful, thank you !

 

ADD REPLYlink written 4.6 years ago by kramdi.a40
Please log in to add an answer.

Help
Access

Use of this site constitutes acceptance of our User Agreement and Privacy Policy.
Powered by Biostar version 16.09
Traffic: 172 users visited in the last hour