On Feb 14, 2013, at 7:26 AM, James wrote:

> Hi Nate,
> 
> Thanks for your reply,
> 
> I guess the idea is that the job is prepared in the interface which lets a 
> user select
> the grid. This is currently located in my galaxy instance as a if statement 
> in the
> default job dispatcher. Just before it sends it to the job runner and all the 
> preparation
> is done there.
> 
> But regarding the command line you are probably right, it would just mean 
> that every job runner
> on our instance will have to be patched to include this if statement as to 
> whether the command line
> needs to be reassigned.

Hi James,

In this case, either method seems fine.  You are going to have to modify the 
way that Galaxy prepares jobs regardless of the way you do it.

> Another simple question regarding adding UI options to toolform.mako. Could i 
> parse them
> to my module using javascript.
> 
> Although I feel the best approach would be to add these options to the
> job model and then they would remain tracked in the database.

There have been various requests in the past to allow for inclusion of a global 
parameter set in tool forms, for this exact purpose.  I thought there was a 
bitbucket issue or trello card for it, but I'm having trouble locating it now.

--nate

> 
> Cheers James.
> 
> On 2/14/2013 4:20 AM, Nate Coraor wrote:
>> On Feb 4, 2013, at 6:03 PM, James Boocock wrote:
>> 
>>> Hi All,
>>> 
>>> I am currently working on a clustering interface for galaxy that will
>>> hopefully enable users to pick the grid
>>> in the tool form.
>>> 
>>> With tools that need access to files within the galaxy directory, I
>>> have an idea to create a symlinked
>>> fake galaxy root with all the files the tools needs for galaxy. This
>>> is done currently in my own xml format
>>> for each grid.
>>> 
>>> Problem is when parsing a tool_wrapper variable I need to prepare the
>>> job and add my additional commands
>>> to the command line so that the fake galaxy dir is created with the
>>> symlinked databases.
>>> 
>>> Is it bad practice to disable preparation in each tool runner if the
>>> job has come from my clustering module
>>> or is there a better way to do this. Will the job runners
>>> wrapper.prepare() overwrite any of my changes to the command-line
>>> when the job makes its way to the runner say local.py.
>> Hi James,
>> 
>> You'll probably need to make the changes to the command line after the 
>> command line has been assembled in prepare().  Can you do this later in 
>> prepare()?
>> 
>> --nate
>> 
>>> 
>>> Cheers James.
>>> ___________________________________________________________
>>> 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:
>>> 
>>>  http://lists.bx.psu.edu/
> 


___________________________________________________________
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:

  http://lists.bx.psu.edu/

Reply via email to