RFC: new param attribute for Galaxy tool XML
Hi all, we are planning to work on a project to implement a Galaxy fuse based shell. Probably starting with the work from Clare [1]. Next to our Galaxy IPython integration it should attract more bioinformaticians and should offer a new way to interact with Galaxy. This includes moving, deleting datasets, but also executing tools and workflows. For the latter I would like to have some sort of bash auto-completion. Type in your tool/workflow and you will see all the parameters you can/should modify, in addition to your normal help page. Currently the parameter identifiers (<param name="foo">) do not need to be meaningful. In fact many tools invent their own unique names, to identify a parameter in the cheetah section. This name is always unique but it's hard to guess it's meaning from just the name and are also not mappable to the original parameter name. This makes tool execution from the API sometimes hard. I would like to propose a new attribute for all <param> tags. This should specify a unique value that 100% matches the original parameter name of the underlying tool. This attribute could be used to: * automatically enhance the help text of each parameter. Currently best practise it to include this parameter in brackets at the end of each help text. We can do this now automatically, or only show it by mouse over etc ... * In a Galaxy shell, the user could just type in a normal command (-i history1/foo.bam -o history1/bar.sam) and Galaxy shell would be able to map this parameter to the correct <param> tag in Galaxy I greatly appreciate any comments! Thanks, Bjoern [1] https://github.com/claresloggett/gvl_commandline_utilities/blob/master/galax...
Hi Björn, Command line arguments are often case sensitive (e.g. samtools switches), but are Galaxy parameter names? Peter On Sat, Feb 28, 2015 at 9:11 PM, Björn Grüning <bjoern.gruening@gmail.com> wrote:
Hi all,
we are planning to work on a project to implement a Galaxy fuse based shell. Probably starting with the work from Clare [1].
Next to our Galaxy IPython integration it should attract more bioinformaticians and should offer a new way to interact with Galaxy. This includes moving, deleting datasets, but also executing tools and workflows. For the latter I would like to have some sort of bash auto-completion. Type in your tool/workflow and you will see all the parameters you can/should modify, in addition to your normal help page.
Currently the parameter identifiers (<param name="foo">) do not need to be meaningful. In fact many tools invent their own unique names, to identify a parameter in the cheetah section. This name is always unique but it's hard to guess it's meaning from just the name and are also not mappable to the original parameter name. This makes tool execution from the API sometimes hard.
I would like to propose a new attribute for all <param> tags. This should specify a unique value that 100% matches the original parameter name of the underlying tool.
This attribute could be used to: * automatically enhance the help text of each parameter. Currently best practise it to include this parameter in brackets at the end of each help text. We can do this now automatically, or only show it by mouse over etc ... * In a Galaxy shell, the user could just type in a normal command (-i history1/foo.bam -o history1/bar.sam) and Galaxy shell would be able to map this parameter to the correct <param> tag in Galaxy
I greatly appreciate any comments! Thanks, Bjoern
[1] https://github.com/claresloggett/gvl_commandline_utilities/blob/master/galax... ___________________________________________________________ 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: https://lists.galaxyproject.org/
To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Peter, Galaxy parameters should be case sensitive I think - they are used in plain dictionaries quite a bit and I have never seen any logic to make them not case sensitive. Bjoern, Is this what you mean? https://github.com/galaxyproject/galaxy/compare/dev...jmchilton:argument_nam... If it is what you want - I can open a pull request for it. I guess I am a little skeptical this is useful. I would like to believe that Galaxy tool for the most part don't need to map to a single application underneath, but we don't have to rehash that argument. If the parameter name and help is not more useful than the underlying tool's parameter - why would the tool author change it in the first place? Jen tells me the parameter name is important, you tell me the parameter name is important, etc... I respect you guys greatly and so I will defer to you - but it is frustrating we are breaking abstractions that the tool author set up (presumably for a reason). -John On Tue, Mar 3, 2015 at 11:38 AM, Peter Cock <p.j.a.cock@googlemail.com> wrote:
Hi Björn,
Command line arguments are often case sensitive (e.g. samtools switches), but are Galaxy parameter names?
Peter
On Sat, Feb 28, 2015 at 9:11 PM, Björn Grüning <bjoern.gruening@gmail.com> wrote:
Hi all,
we are planning to work on a project to implement a Galaxy fuse based shell. Probably starting with the work from Clare [1].
Next to our Galaxy IPython integration it should attract more bioinformaticians and should offer a new way to interact with Galaxy. This includes moving, deleting datasets, but also executing tools and workflows. For the latter I would like to have some sort of bash auto-completion. Type in your tool/workflow and you will see all the parameters you can/should modify, in addition to your normal help page.
Currently the parameter identifiers (<param name="foo">) do not need to be meaningful. In fact many tools invent their own unique names, to identify a parameter in the cheetah section. This name is always unique but it's hard to guess it's meaning from just the name and are also not mappable to the original parameter name. This makes tool execution from the API sometimes hard.
I would like to propose a new attribute for all <param> tags. This should specify a unique value that 100% matches the original parameter name of the underlying tool.
This attribute could be used to: * automatically enhance the help text of each parameter. Currently best practise it to include this parameter in brackets at the end of each help text. We can do this now automatically, or only show it by mouse over etc ... * In a Galaxy shell, the user could just type in a normal command (-i history1/foo.bam -o history1/bar.sam) and Galaxy shell would be able to map this parameter to the correct <param> tag in Galaxy
I greatly appreciate any comments! Thanks, Bjoern
[1] https://github.com/claresloggett/gvl_commandline_utilities/blob/master/galax... ___________________________________________________________ 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: https://lists.galaxyproject.org/
To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
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: https://lists.galaxyproject.org/
To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Am 04.03.2015 um 02:37 schrieb John Chilton:
Peter,
Galaxy parameters should be case sensitive I think - they are used in plain dictionaries quite a bit and I have never seen any logic to make them not case sensitive.
I think so too, never tried it but I guess they are case sensitive and no '-' is allowed.
Bjoern,
Is this what you mean?
https://github.com/galaxyproject/galaxy/compare/dev...jmchilton:argument_nam...
Pretty much yes!
If it is what you want - I can open a pull request for it.
I was posting it here to get a small discussion started. If there are no complains and every one is happy, please do so :)
I guess I am a little skeptical this is useful. I would like to believe that Galaxy tool for the most part don't need to map to a single application underneath, but we don't have to rehash that argument. If the parameter name and help is not more useful than the underlying tool's parameter - why would the tool author change it in the first place?
Can you elaborate here a little bit more? My point is that the actual parameter _is_ important to map against the original tool documentation, some pdfs etc. It's also important to map some paper's method section back to a Galaxy tool. So I think it should be available for the user. Currently, best practise is to put it into help. This is good, but clutters the UI and it is unstructured. Unstructured in a way, so that I can not easily get it, for example via the API. If we have this information as extra attribute we display it in a special way in the new JS tool form, independent from the help text. And I could get this information to do nasty things on a potential GalaxyShell with it.
Jen tells me the parameter name is important, you tell me the parameter name is important, etc... I respect you guys greatly and so I will defer to you - but it is frustrating we are breaking abstractions that the tool author set up (presumably for a reason).
Which abstraction do we break? Do you have an example? I think in most of the cases a param maps one-to-one to an argument, isn't? (There are special cases, but this does not go away and need to stay.) I think this attribute is just an additional way to structure our params and make it easier to map and document them. Thanks, this kind of discussion I wanted to have :) Cheers, Bjoern
-John
On Tue, Mar 3, 2015 at 11:38 AM, Peter Cock <p.j.a.cock@googlemail.com> wrote:
Hi Björn,
Command line arguments are often case sensitive (e.g. samtools switches), but are Galaxy parameter names?
Peter
On Sat, Feb 28, 2015 at 9:11 PM, Björn Grüning <bjoern.gruening@gmail.com> wrote:
Hi all,
we are planning to work on a project to implement a Galaxy fuse based shell. Probably starting with the work from Clare [1].
Next to our Galaxy IPython integration it should attract more bioinformaticians and should offer a new way to interact with Galaxy. This includes moving, deleting datasets, but also executing tools and workflows. For the latter I would like to have some sort of bash auto-completion. Type in your tool/workflow and you will see all the parameters you can/should modify, in addition to your normal help page.
Currently the parameter identifiers (<param name="foo">) do not need to be meaningful. In fact many tools invent their own unique names, to identify a parameter in the cheetah section. This name is always unique but it's hard to guess it's meaning from just the name and are also not mappable to the original parameter name. This makes tool execution from the API sometimes hard.
I would like to propose a new attribute for all <param> tags. This should specify a unique value that 100% matches the original parameter name of the underlying tool.
This attribute could be used to: * automatically enhance the help text of each parameter. Currently best practise it to include this parameter in brackets at the end of each help text. We can do this now automatically, or only show it by mouse over etc ... * In a Galaxy shell, the user could just type in a normal command (-i history1/foo.bam -o history1/bar.sam) and Galaxy shell would be able to map this parameter to the correct <param> tag in Galaxy
I greatly appreciate any comments! Thanks, Bjoern
[1] https://github.com/claresloggett/gvl_commandline_utilities/blob/master/galax... ___________________________________________________________ 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: https://lists.galaxyproject.org/
To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
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: https://lists.galaxyproject.org/
To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
participants (3)
-
Björn Grüning -
John Chilton -
Peter Cock