find UUID of current history in tool XML wrapper?

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

find UUID of current history in tool XML wrapper?

Ben Bimber
Hello,

I am trying to pass the UUID or name of the current history to a script as part of a tool XML wrapper.  I was hoping some substitution like ${output.hid}, ${history_id} or similar would give this, but have not had luck.  Is there an approach to do this?

On a related note: does anyone have debugging tips or pointers to code that would help me figure out which substitutions galaxy will support?  The tool wrapper docs list some; however, this isnt complete.

Thanks in advance,
Ben

___________________________________________________________
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 | Threaded
Open this post in threaded view
|

Re: find UUID of current history in tool XML wrapper?

John Chilton-4
There is some discussion of this here -
https://biostar.usegalaxy.org/p/11972/#12000. The community clearly
wants this functionality but there was unfortunate resistance to
adding history context information to the tool evaluation framework in
the past.

-John

On Mon, May 4, 2015 at 2:28 PM, Ben Bimber <[hidden email]> wrote:

> Hello,
>
> I am trying to pass the UUID or name of the current history to a script as
> part of a tool XML wrapper.  I was hoping some substitution like
> ${output.hid}, ${history_id} or similar would give this, but have not had
> luck.  Is there an approach to do this?
>
> On a related note: does anyone have debugging tips or pointers to code that
> would help me figure out which substitutions galaxy will support?  The tool
> wrapper docs list some; however, this isnt complete.
>
> Thanks in advance,
> Ben
>
> ___________________________________________________________
> 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 | Threaded
Open this post in threaded view
|

Re: find UUID of current history in tool XML wrapper?

Dooley, Damion
In reply to this post by Ben Bimber
About
   1. find UUID of current history in tool XML wrapper? (Ben Bimber)
   2. Re: find UUID of current history in tool XML wrapper?
      (John Chilton)

I think this will work for you, I've simplified the code.  I was able to do this somewhat circuitously (=bonfire of time) for my upcoming Versioned Data tool.  In your tool XML definition file:

        <param name="history_id" display="radio" type="drill_down" dynamic_options="vdb_init_tool_user(__trans__)" />
        ...
        <code file="versioned_data_form.py" />
       
Not sure if making history_id a hidden field would work (I seemed to recall __trans__ variable only exposed to select param).

And in a script named versioned_data_form.py we have:

def vdb_init_tool_user(trans):
        """
        ...
        ALSO: squeezing history_id in this way since no other way to pass it.
        "trans" is provided only by tool form presentation via <code file="...">
        ...
        """
        history_id = str(trans.security.encode_id(trans.history.id))

        items = [ { 'name': 'think of something to say here', 'value': history_id, 'options':[], 'selected': True } ]

        return items
___________________________________________________________
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 | Threaded
Open this post in threaded view
|

Re: find UUID of current history in tool XML wrapper?

Ben Bimber
Hi Damion,

Possibly a dumb question, but I thought I'd ask: if i understand your example, you're basically end-running galaxy due to the fact that for dynamic options you can execute code.  When this is called, galaxy passes in an object that lets you access the current history ID.

In other contexts, I have seen code within <configfile> or similar blocks that seems to essentially be calling native python code as well.  Can a similar approach be used to accomplish what you're doing more directly?  For example, the other day John Chilton posted this example for the API key:

#from galaxy.managers import api_keys#
${api_keys.ApiKeyManager( $__app__ ).get_or_create_api_key( $__user__ )}

If I'm already using non-public APIs to get the current history ID, can it be done more directly using something analogous to the above?

Thanks,
Ben


On Tue, May 5, 2015 at 10:33 AM, Dooley, Damion <[hidden email]> wrote:
About
   1. find UUID of current history in tool XML wrapper? (Ben Bimber)
   2. Re: find UUID of current history in tool XML wrapper?
      (John Chilton)

I think this will work for you, I've simplified the code.  I was able to do this somewhat circuitously (=bonfire of time) for my upcoming Versioned Data tool.  In your tool XML definition file:

        <param name="history_id" display="radio" type="drill_down" dynamic_options="vdb_init_tool_user(__trans__)" />
        ...
        <code file="versioned_data_form.py" />

Not sure if making history_id a hidden field would work (I seemed to recall __trans__ variable only exposed to select param).

And in a script named versioned_data_form.py we have:

def vdb_init_tool_user(trans):
        """
        ...
        ALSO: squeezing history_id in this way since no other way to pass it.
        "trans" is provided only by tool form presentation via <code file="...">
        ...
        """
        history_id = str(trans.security.encode_id(trans.history.id))

        items = [ { 'name': 'think of something to say here', 'value': history_id, 'options':[], 'selected': True } ]

        return items
___________________________________________________________
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 | Threaded
Open this post in threaded view
|

Re: find UUID of current history in tool XML wrapper?

Dooley, Damion
Yes, stooping to using <code> in the workaround.  What I remember is that it was only via the dynamic_options() call that I had access to __trans__ variable.  If someone on dev knows of another way to get __trans__ stuff via cheeta directly in the XML definition file that would be great.

Cheers,

Damion

Hsiao lab, BC Public Health Microbiology & Reference Laboratory, BC Centre for Disease Control
655 West 12th Avenue, Vancouver, British Columbia, V5Z 4R4 Canada
________________________________________
From: Ben Bimber [[hidden email]]
Sent: Tuesday, May 05, 2015 11:08 AM
To: Dooley, Damion
Cc: [hidden email]
Subject: Re: [galaxy-dev] find UUID of current history in tool XML wrapper?

Hi Damion,

Possibly a dumb question, but I thought I'd ask: if i understand your example, you're basically end-running galaxy due to the fact that for dynamic options you can execute code.  When this is called, galaxy passes in an object that lets you access the current history ID.

In other contexts, I have seen code within <configfile> or similar blocks that seems to essentially be calling native python code as well.  Can a similar approach be used to accomplish what you're doing more directly?  For example, the other day John Chilton posted this example for the API key:

#from galaxy.managers import api_keys#
${api_keys.ApiKeyManager( $__app__ ).get_or_create_api_key( $__user__ )}

If I'm already using non-public APIs to get the current history ID, can it be done more directly using something analogous to the above?

Thanks,
Ben
___________________________________________________________
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 | Threaded
Open this post in threaded view
|

Re: find UUID of current history in tool XML wrapper?

Dooley, Damion
In reply to this post by Ben Bimber
P.s. I tried using BioBlend and(or) the Galaxy API to get a given user's current history but found there was no way to do so.  

Seems like there is occasionally a tension between "plaform by design" (reduced instruction set, occasionally with security in mind, or dev resource limitations) and "platform for creativity" (everything exposed in case someone might find use for it).

d.

Hsiao lab, BC Public Health Microbiology & Reference Laboratory, BC Centre for Disease Control
655 West 12th Avenue, Vancouver, British Columbia, V5Z 4R4 Canada
________________________________________
From: Ben Bimber [[hidden email]]
...

If I'm already using non-public APIs to get the current history ID, can it be done more directly using something analogous to the above?

Thanks,
Ben
___________________________________________________________
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 | Threaded
Open this post in threaded view
|

Re: find UUID of current history in tool XML wrapper?

John Chilton-4
I had an epiphany - I think the follow idioms will let you get the
current history id and current history name. It is more robust than
the code file trick because it will also work with direct API calls
where there is no "current history" (doesn't require use of trans).

https://gist.github.com/jmchilton/27c5bb05e155a611294d

-John


On Tue, May 5, 2015 at 3:11 PM, Dooley, Damion <[hidden email]> wrote:

> P.s. I tried using BioBlend and(or) the Galaxy API to get a given user's current history but found there was no way to do so.
>
> Seems like there is occasionally a tension between "plaform by design" (reduced instruction set, occasionally with security in mind, or dev resource limitations) and "platform for creativity" (everything exposed in case someone might find use for it).
>
> d.
>
> Hsiao lab, BC Public Health Microbiology & Reference Laboratory, BC Centre for Disease Control
> 655 West 12th Avenue, Vancouver, British Columbia, V5Z 4R4 Canada
> ________________________________________
> From: Ben Bimber [[hidden email]]
> ...
>
> If I'm already using non-public APIs to get the current history ID, can it be done more directly using something analogous to the above?
>
> Thanks,
> Ben
> ___________________________________________________________
> 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 | Threaded
Open this post in threaded view
|

Re: find UUID of current history in tool XML wrapper?

Dannon Baker-2
In reply to this post by Dooley, Damion
Galaxy's API goal is to be intentionally stateless, and methods that operate on a history accept that as a parameter and don't recognize the notion of 'current'.  State like that is to be maintained in the client, whatever that is -- whether a webpage, cron job, etc.  I think this approach is probably *more* flexible in that we don't box ourselves into relying on the notion of a 'current' history, though some few methods might currently rely on it.

It's worth noting that this argument has conspicuous parallels to the argument against allowing tools to understand the 'current' history as well.

On Tue, May 5, 2015 at 3:11 PM Dooley, Damion <[hidden email]> wrote:
P.s. I tried using BioBlend and(or) the Galaxy API to get a given user's current history but found there was no way to do so.

Seems like there is occasionally a tension between "plaform by design" (reduced instruction set, occasionally with security in mind, or dev resource limitations) and "platform for creativity" (everything exposed in case someone might find use for it).

d.

Hsiao lab, BC Public Health Microbiology & Reference Laboratory, BC Centre for Disease Control
655 West 12th Avenue, Vancouver, British Columbia, V5Z 4R4 Canada
________________________________________
From: Ben Bimber [[hidden email]]
...

If I'm already using non-public APIs to get the current history ID, can it be done more directly using something analogous to the above?

Thanks,
Ben
___________________________________________________________
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 | Threaded
Open this post in threaded view
|

Re: find UUID of current history in tool XML wrapper?

Ben Bimber
Thanks to all of you for the comments and code help.  John's example is grabbing the target history for the output, which is actually perfect for us.  i get that 'current history' doesnt really mean anything, and the target history for the output file is a far more reliable option.  I simplified the example to:

$__tool_directory__/import_datasets_by_uuid.py -A $script_file -H "${output.creating_job.history.name}" -f ${output}

which is working perfectly.  

I think my use cases and the example a few days ago from doug king all fall under the header of 'attempting to use the bioblend API from within a tool wrapper, executed via galaxy'.  in those cases, being able to pass in some context about the current execution are required to get a reliable result.  I get why it isnt support well right now, but I would argue that sort of application isnt inherently a misuse of galaxy.

-Ben

On Tue, May 5, 2015 at 12:14 PM, Dannon Baker <[hidden email]> wrote:
Galaxy's API goal is to be intentionally stateless, and methods that operate on a history accept that as a parameter and don't recognize the notion of 'current'.  State like that is to be maintained in the client, whatever that is -- whether a webpage, cron job, etc.  I think this approach is probably *more* flexible in that we don't box ourselves into relying on the notion of a 'current' history, though some few methods might currently rely on it.

It's worth noting that this argument has conspicuous parallels to the argument against allowing tools to understand the 'current' history as well.

On Tue, May 5, 2015 at 3:11 PM Dooley, Damion <[hidden email]> wrote:
P.s. I tried using BioBlend and(or) the Galaxy API to get a given user's current history but found there was no way to do so.

Seems like there is occasionally a tension between "plaform by design" (reduced instruction set, occasionally with security in mind, or dev resource limitations) and "platform for creativity" (everything exposed in case someone might find use for it).

d.

Hsiao lab, BC Public Health Microbiology & Reference Laboratory, BC Centre for Disease Control
655 West 12th Avenue, Vancouver, British Columbia, V5Z 4R4 Canada
________________________________________
From: Ben Bimber [[hidden email]]
...

If I'm already using non-public APIs to get the current history ID, can it be done more directly using something analogous to the above?

Thanks,
Ben
___________________________________________________________
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 | Threaded
Open this post in threaded view
|

Re: find UUID of current history in tool XML wrapper?

John Chilton-4
On Tue, May 5, 2015 at 3:40 PM, Ben Bimber <[hidden email]> wrote:

> Thanks to all of you for the comments and code help.  John's example is
> grabbing the target history for the output, which is actually perfect for
> us.  i get that 'current history' doesnt really mean anything, and the
> target history for the output file is a far more reliable option.  I
> simplified the example to:
>
> $__tool_directory__/import_datasets_by_uuid.py -A $script_file -H
> "${output.creating_job.history.name}" -f ${output}
>
> which is working perfectly.

Wonderful!

>
> I think my use cases and the example a few days ago from doug king all fall
> under the header of 'attempting to use the bioblend API from within a tool
> wrapper, executed via galaxy'.  in those cases, being able to pass in some
> context about the current execution are required to get a reliable result.
> I get why it isnt support well right now, but I would argue that sort of
> application isnt inherently a misuse of galaxy.

Agreed entirely!

-John

>
> -Ben
>
> On Tue, May 5, 2015 at 12:14 PM, Dannon Baker <[hidden email]>
> wrote:
>>
>> Galaxy's API goal is to be intentionally stateless, and methods that
>> operate on a history accept that as a parameter and don't recognize the
>> notion of 'current'.  State like that is to be maintained in the client,
>> whatever that is -- whether a webpage, cron job, etc.  I think this approach
>> is probably *more* flexible in that we don't box ourselves into relying on
>> the notion of a 'current' history, though some few methods might currently
>> rely on it.
>>
>> It's worth noting that this argument has conspicuous parallels to the
>> argument against allowing tools to understand the 'current' history as well.
>>
>> On Tue, May 5, 2015 at 3:11 PM Dooley, Damion <[hidden email]>
>> wrote:
>>>
>>> P.s. I tried using BioBlend and(or) the Galaxy API to get a given user's
>>> current history but found there was no way to do so.
>>>
>>> Seems like there is occasionally a tension between "plaform by design"
>>> (reduced instruction set, occasionally with security in mind, or dev
>>> resource limitations) and "platform for creativity" (everything exposed in
>>> case someone might find use for it).
>>>
>>> d.
>>>
>>> Hsiao lab, BC Public Health Microbiology & Reference Laboratory, BC
>>> Centre for Disease Control
>>> 655 West 12th Avenue, Vancouver, British Columbia, V5Z 4R4 Canada
>>> ________________________________________
>>> From: Ben Bimber [[hidden email]]
>>> ...
>>>
>>> If I'm already using non-public APIs to get the current history ID, can
>>> it be done more directly using something analogous to the above?
>>>
>>> Thanks,
>>> Ben
>>> ___________________________________________________________
>>> 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 | Threaded
Open this post in threaded view
|

Re: find UUID of current history in tool XML wrapper?

Dooley, Damion
In reply to this post by Dannon Baker-2
First, John, that "$output_dataset.creating_job.history.id" looks great!

Ok, Dannon, I see various merits of stateless design - always providing server processes with the entire input array (files, params) in which no server state memory is referenced for a given user/agent task (aside from user state permissions).  

So I'm thinking John's solution is copacetic because it expresses that we're after a piece of information about the current process - where it is delivering its output - since we have other immediate processes that need to contribute to that work.

Thanks for your attention in revisiting this matter!

d.

Hsiao lab, BC Public Health Microbiology & Reference Laboratory, BC Centre for Disease Control
655 West 12th Avenue, Vancouver, British Columbia, V5Z 4R4 Canada
________________________________________
From: Dannon Baker [[hidden email]]
...
Subject: Re: [galaxy-dev] find UUID of current history in tool XML wrapper?

Galaxy's API goal is to be intentionally stateless, and methods that operate on a history accept that as a parameter and don't recognize the notion of 'current'.  State like that is to be maintained in the client, whatever that is -- whether a webpage, cron job, etc.  I think this approach is probably *more* flexible in that we don't box ourselves into relying on the notion of a 'current' history, though some few methods might currently rely on it.

It's worth noting that this argument has conspicuous parallels to the argument against allowing tools to understand the 'current' history as well.
___________________________________________________________
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/