Re: [galaxy-dev] [galaxy-user] Questions regarding Galaxy Tool XML File
This question is best directed to the galaxy-dev mailing list because it concerns developing around Galaxy, so I've moved it there.
However, if I understand it right, the idea of the XML tool config is to provide a description of the galaxy graphical user interface rather then a general description of the actual tool's interface.
No, the XML config describes a tool in abstract/essence: inputs, parameters, and outputs. Rendering of a tool can be done any number of ways.
- param tag: I havent really understood how you define a parameter to be mandatory or optional. I see when it is the child of the repeat element that there is (maybe) a minimum defined. But when this is not the case, how can I conclude that the parameter is optional vs. mandatory ?
Parameters have an 'optional' attribute. See here for details on tool and parameter config in general: http://wiki.galaxyproject.org/Admin/Tools/ToolConfigSyntax
- param tag's help attribute: can I assume any format, or is it simply the output of the tools help command ?
Format is simply text.
- when do you update the tools and in turn the XML configs. (e.g. the gatk stuff is kind of outdated: 1.4 vs 2.6 )
The depends on a number of factors, including tool stability, dependencies, usage level, and ease of updating. The tool shed makes it easy to follow tool updates for a local instance: http://wiki.galaxyproject.org/Tool%20Shed You might be able to reuse some of that code in a stand-alone script. Good luck, J.
This question is best directed to the galaxy-dev mailing list because it concerns developing around Galaxy, so I've moved it there.
However, if I understand it right, the idea of the XML tool config is to provide a description of the galaxy graphical user interface rather then a general description of the actual tool's interface.
No, the XML config describes a tool in abstract/essence: inputs, parameters, and outputs. Rendering of a tool can be done any number of ways.
- param tag: I havent really understood how you define a parameter to be mandatory or optional. I see when it is the child of the repeat element that there is (maybe) a minimum defined. But when this is not the case, how can I conclude that the parameter is optional vs. mandatory ?
Parameters have an 'optional' attribute. See here for details on tool and parameter config in general:
http://wiki.galaxyproject.org/Admin/Tools/ToolConfigSyntax For example lets consider the gatk's depth_of_coverage.xml together with
Hi and thank you for the response ! I have a little few more questions. See below. Jeremy Goecks wrote: the gatk_macros.xml: There is exactly one parameter (input_calculate_coverage_over_genes) defined as optional. I know that most of the tools parameters are indeed optional and a default value is internally assumed. As it is generally the case of gatk that only the input, reference and output file and a few more parameters have to be passed to the tool and the rest can be omitted, i.e. are optional. However, one might get the impression, that the conditional tag somehow overlaps this: In the sense that the allowed parameter values are enumerated (in combination with option tag) and a default value is defined (and passed to the execution engine). Doing so the galaxy tool interface finally presents these parameter option values to the user (and the user can optionally select a non default value). As an example see the parameter "--interval_set_rule UNION" (is rendered when the advanced dialog is opened) which is an optional parameter that is not explicitly marked as optional. Question: How save is the optional attribute ? I mean how consequent are you in this matter when the tool definition xml is to be created. Is there any relation to the conditional tag ? Another question: Have you ever thought about pipes. It seems that the tool xml schema entirely ignores it. For instance one could easily tag an input parameter to be able to read from stdin or to write to stdout/stderr. Especially samtools and bedtools do support pipes. Is there an obvious reason not to use it ? Thanks, Marian
Question: How save is the optional attribute ? I mean how consequent are you in this matter when the tool definition xml is to be created.
It's not clear to me what you're asking. That said, it's important to distinguish between Galaxy tool wrappers and their corresponding tools. Either deliberately or inadvertently, the wrapper may have different behavior than the tool. For example, an optional tool parameter may not be optional in the Galaxy wrapper because the wrapper author believes that explicitly setting a value is critical.
Is there any relation to the conditional tag ?
No relation, but there can certainly be some confusion between conditional and optional parameters. It's not clear what the best way to solve this issue is.
Another question: Have you ever thought about pipes. It seems that the tool xml schema entirely ignores it. For instance one could easily tag an input parameter to be able to read from stdin or to write to stdout/stderr. Especially samtools and bedtools do support pipes. Is there an obvious reason not to use it ?
Galaxy's treats each tool run autonomously right now; e.g., each tool run is submitted to the cluster as a separate job. This approach prevents pipes from being used. However, we are definitely interested in extending Galaxy to support piping in the future. J.
participants (2)
-
Jeremy Goecks -
Marian Thieme