Re: [galaxy-dev] Changing job command line.

2013-02-19 Thread Nate Coraor

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/


Re: [galaxy-dev] Changing job command line.

2013-02-14 Thread James

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.

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.

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/


Re: [galaxy-dev] Changing job command line.

2013-02-13 Thread Nate Coraor
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/