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

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/

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/

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.