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
___
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/
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
On Tue, May 5, 2015 at 10:33 AM, Dooley, Damion damion.doo...@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/
___
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/
Re: [galaxy-dev] find UUID of current history in tool XML wrapper?
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 [bbim...@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/
Re: [galaxy-dev] find UUID of current history in tool XML wrapper?
On Tue, May 5, 2015 at 3:40 PM, Ben Bimber bbim...@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.ba...@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.doo...@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 [bbim...@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/
___
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/
Re: [galaxy-dev] find UUID of current history in tool XML wrapper?
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.ba...@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.doo...@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 [bbim...@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/
Re: [galaxy-dev] find UUID of current history in tool XML wrapper?
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.ba...@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. ___ 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/
Re: [galaxy-dev] find UUID of current history in tool XML wrapper?
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 bbim...@gmail.com 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/
