Re: [galaxy-dev] find UUID of current history in tool XML wrapper?
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
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 <Damion.Dooley@bccdc.ca> 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/
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 [bbimber@gmail.com] Sent: Tuesday, May 05, 2015 11:08 AM To: Dooley, Damion Cc: galaxy-dev@lists.galaxyproject.org 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
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 [bbimber@gmail.com] ... 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
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 <Damion.Dooley@bccdc.ca> 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 [bbimber@gmail.com] ...
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/
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 <Damion.Dooley@bccdc.ca> 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 [bbimber@gmail.com] ...
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/
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 <dannon.baker@gmail.com> 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 <Damion.Dooley@bccdc.ca> 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 [bbimber@gmail.com] ...
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/
On Tue, May 5, 2015 at 3:40 PM, Ben Bimber <bbimber@gmail.com> 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 <dannon.baker@gmail.com> 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 <Damion.Dooley@bccdc.ca> 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 [bbimber@gmail.com] ...
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/
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 [dannon.baker@gmail.com] ... 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.
participants (4)
-
Ben Bimber -
Dannon Baker -
Dooley, Damion -
John Chilton