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_name?expand=1

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.c...@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.gruen...@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/galaxy-fuse.py
>>> ___________________________________________________________
>>> 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/
___________________________________________________________
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/

Reply via email to