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 klin938@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 greg@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_incl...

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/