Add argument to tool parameters.

[jmchilton]

• Expose via the API to help command-line construction.
• Default the name of a parameter to be this (minus dashes) if name is not otherwise found.

[dannon]

This is an automated message. Thanks for your contribution, a Trello card to track this issue has been created. Apply this patch for testing.

[dannon]

Is there a missing commit here? On initial startup of Galaxy I'm seeing all tool parsing fail because no input source has an argument attribute.

[jmchilton]

None of the tools in Galaxy load you say? Huh - thanks - nice catch - such a subtle problem though I am not surprised I missed it.

I've updated the PR to be much less obviously broken.

[bgruening]

@jmchilton this means that you can create a param without a name and it will take the stripped argument?
I don't think we should allow this. name should be required, argument and be optional and needs to be unstripped (for UI and gsh.)

[jmchilton]

It shouldn't modify argument - to me it makes sense that if you specify the argument as --input - the name can safely be inferred to be input. This provides some actual convenience to tool authors annotating things this way - argument will still be --input.

Put another way...

<param name="input" argument="--input"... 

feels redundant right?

[dannon]

I'd put it the other way 'round. You can always refer to a parameter as
--{name} (as an argument) if argument isn't specified. Name is always
required.

On Fri, Mar 6, 2015 at 4:08 PM John Chilton notifications@github.com
wrote:

In lib/galaxy/tools/parameters/basic.py
#8 (comment):

@@ -235,6 +234,17 @@ def build( cls, tool, param ):
else:
return parameter_types[param_type](tool, param)

• @classmethod
• def parse_name(cls, input_source):

•    name = input_source.get("name", None)
  

•    if name is None:
  

•        argument = input_source.get("argument")
  

•        if argument:
  

•            name = argument.lstrip("-")
  

•        else:
  

It shouldn't modify argument - to me it makes sense that if you specify
the argument as --input - the name can safely be inferred to be input.
This provides some actual convenience to tool authors annotating things
this way - argument will still be --input.

Put another way...

feels redundant right?

—
Reply to this email directly or view it on GitHub
https://github.com/galaxyproject/galaxy/pull/8/files#r25978130.

[bgruening]

Ok, I see. Thought this will modify argument. Nice! 👍

[jmchilton]

All existing tools would have parameters that are then annotated as having arguments that may have nothing to do with the underlying application or wrapper then.

[dannon]

Ahhh, I see what you guys are trying to do now, I think. So, yeah, that wouldn't work. I still don't like making name optional (if you have the optional argument).

[martenson]

This is good to go, right @jmchilton ?

[jmchilton]

@martenson Lets give it a couple more days - I have some ideas to make it more clearly awesome and James mentioned he may have issues (though he was coming around on the idea last time I heard).

[bgruening]

@guerler is it possible to parse a tool parameter for argument="" and add the (--parameter) string at the end of the help="" automatically?

[guerler]

@bgruening Parse it from where? The tool form? And what do you mean with end of help? Do you mean a separate section, listing all argument names? I need a few more details here. (:

[hexylena]

@guerler from the argument parameter of the parameter definition.

E.g.:

  <param name="s" argument="-s" label="Some Parameter" help="wibbles wobbles" type="text" />

would automatically be rendered as:

  <param name="s" argument="-s" label="Some Parameter" help="wibbles wobbles (-s)" type="text" />

from the value of the argument parameter.

[bgruening]

@guerler In our best practice guide we state that we want to have (--argument) somewhere mentioned. http://galaxy-iuc-standards.readthedocs.org/en/latest/best_practices/tool_xml.html#parameter-help
Would be nice if the toolform can handle this automatically, either by attaching it to the normal help text or by hovering over an info button(?). You are more creative than me ... but we want the original parameter name available in to toolform, if possible.

[guerler]

Thanks @erasche. Yes, this is possible. One option would be to make sure that the --argument is parsed through the tools parameters to_dict() function, and then we could attach it to the tool parameters help text on the front-end.

[jmchilton]

Thanks @guerler - I believe it is in the to_dict function.

[guerler]

Yeah, I think so too. I'll look into it.