Re: [galaxy-dev] How to make toolshed tool to create dummy env.sh

2012-11-12 Thread Greg Von Kuster
Hi Kevin,

I'm not clear why you want to create a dummy env.sh file, so I may not be 
able to answer your question.  However, see the following tool shed wiki page 
in case you want to create an env.sh file that is sourced when the tool(s) 
included in the installed repository is executed in the Galaxy instance in case 
this is what you're looking for.

http://wiki.galaxyproject.org/ToolShedToolFeatures#Finding_dependencies_included_in_an_installed_repository_at_tool_execution_time

Greg Von Kuster


On Nov 12, 2012, at 1:51 AM, Kevin Y wrote:

 Hi dev list,
 
 What is the simplest xml I can put into a tool_dependencies.xml
 for it to create a dummy env.sh in tool-dependency/tool/version/
 /awef234243/env.sh
 
 And will this be sourced each time. Or does the dependency need to be
 some sort of successfully install status for it to be sourced?
 
 Ideally I would be elegant if there is a way to create this env.sh
 easily as it's the best way for a galaxy admin to manage the different
 versions of dependencies.
 
 Thanks,
 Kevin.
 ___
 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] How to make toolshed tool to create dummy env.sh

2012-11-12 Thread Derrick Lin
Hi Greg,

I am wondering the similar thing. If I understand Kevin's post correctly, I
think the question really is: if the automated tools build is
the requirement for creating the shed tool version specific env.sh
automatically during the shed tool installation.

Take BWA on the Tool Shed as an example, during the installation, BWA
binary was built on the fly and  the path
tool-dependency/bwa/0.5.9/devteam/bwa_wrappers/ffa8aaa14f7c/env.sh was
created.

But in some cases, the automated tools build is not desirable. On the
cluster that serves our Galaxy, we have had BWA compiled with the hardware
optimized compiler, and I simply want to put existing BWA path to the
env.sh without compiling another BWA that will not be used.

So it makes sense (at least to me) that the shed tool installation always
create the specific env.sh and provides the automated tools build as an
option.

Cheers,
Derrick



On Tue, Nov 13, 2012 at 8:21 AM, Greg Von Kuster g...@bx.psu.edu wrote:

 Hi Kevin,

 I'm not clear why you want to create a dummy env.sh file, so I may not
 be able to answer your question.  However, see the following tool shed wiki
 page in case you want to create an env.sh file that is sourced when the
 tool(s) included in the installed repository is executed in the Galaxy
 instance in case this is what you're looking for.


 http://wiki.galaxyproject.org/ToolShedToolFeatures#Finding_dependencies_included_in_an_installed_repository_at_tool_execution_time

 Greg Von Kuster


 On Nov 12, 2012, at 1:51 AM, Kevin Y wrote:

  Hi dev list,
 
  What is the simplest xml I can put into a tool_dependencies.xml
  for it to create a dummy env.sh in tool-dependency/tool/version/
  /awef234243/env.sh
 
  And will this be sourced each time. Or does the dependency need to be
  some sort of successfully install status for it to be sourced?
 
  Ideally I would be elegant if there is a way to create this env.sh
  easily as it's the best way for a galaxy admin to manage the different
  versions of dependencies.
 
  Thanks,
  Kevin.
  ___
  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/

___
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] How to make toolshed tool to create dummy env.sh

2012-11-12 Thread Kevin Y
Hi All,
That's the idea.
An env.sh for each toolshed tool (or tool dependency). Everything is
generic and modular this way, while giving us better control over
versions, and control over compilation settings.

Here is something I've tried.
install version=1.0
  actions
action type=set_environment
  environment_variable name=PATH
action=prepend_to$INSTALL_DIR/bin/environment_variable
/action
  /actions
/install

The tool installs but the tool dependency install fails.
I've tried variations by touching a file and moving it to
$INSTALL_DIR. But It only seems to work when I download and make
something (which I managed for meme_chip).
So I guess there is a lot of magic that I don't understand.

Ideally when I wrap a toolshed tool It can just generate a env.sh that
is tied to this specific revision (tool wrapper version) eg.
ffa8aaa14f7c
When a tool version changes and the wrapper changes a different env.sh
can be made and point to a different version of the tool.
iiwkerufh234f
All the while the admin can easily modify these without messily
creating his/her own env.sh's

At the moment we have everything as accessible through the command
line so it's impossible to separate different tool versions without
separate env.sh. But again it would be better for the toolshed tool to
create these rather than the admin.

Cheers,
Kevin.

On 13 November 2012 12:36, Derrick Lin klin...@gmail.com wrote:
 Hi Greg,

 I am wondering the similar thing. If I understand Kevin's post correctly, I
 think the question really is: if the automated tools build is the
 requirement for creating the shed tool version specific env.sh automatically
 during the shed tool installation.

 Take BWA on the Tool Shed as an example, during the installation, BWA binary
 was built on the fly and  the path
 tool-dependency/bwa/0.5.9/devteam/bwa_wrappers/ffa8aaa14f7c/env.sh was
 created.

 But in some cases, the automated tools build is not desirable. On the
 cluster that serves our Galaxy, we have had BWA compiled with the hardware
 optimized compiler, and I simply want to put existing BWA path to the env.sh
 without compiling another BWA that will not be used.

 So it makes sense (at least to me) that the shed tool installation always
 create the specific env.sh and provides the automated tools build as an
 option.

 Cheers,
 Derrick



 On Tue, Nov 13, 2012 at 8:21 AM, Greg Von Kuster g...@bx.psu.edu wrote:

 Hi Kevin,

 I'm not clear why you want to create a dummy env.sh file, so I may not
 be able to answer your question.  However, see the following tool shed wiki
 page in case you want to create an env.sh file that is sourced when the
 tool(s) included in the installed repository is executed in the Galaxy
 instance in case this is what you're looking for.


 http://wiki.galaxyproject.org/ToolShedToolFeatures#Finding_dependencies_included_in_an_installed_repository_at_tool_execution_time

 Greg Von Kuster


 On Nov 12, 2012, at 1:51 AM, Kevin Y wrote:

  Hi dev list,
 
  What is the simplest xml I can put into a tool_dependencies.xml
  for it to create a dummy env.sh in tool-dependency/tool/version/
  /awef234243/env.sh
 
  And will this be sourced each time. Or does the dependency need to be
  some sort of successfully install status for it to be sourced?
 
  Ideally I would be elegant if there is a way to create this env.sh
  easily as it's the best way for a galaxy admin to manage the different
  versions of dependencies.
 
  Thanks,
  Kevin.
  ___
  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/


___
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/