I could be wrong but I think the <install> tag should have some sort of download action - I don't think tools are actually stuck in $INSTALL_DIR like this - $INSTALL_DIR is where you can move or compile downloaded files to. You might want to try $REPOSITORY_INSTALL_DIR instead of $INSTALL_DIR - but really if you are going to just stick an application next to your tool wrapper like this (I would consider this an anti-pattern) I would just set your PATH in mytool.sh and not worry about the tool shed install stuff at all. Maybe add something like PATH=`dirname $0`/bin:$PATH export PATH To the wrapper mytool.sh. As I mentioned - I think bundling applications with tools like this is something of an anti-pattern even if you can make it work. The best practice here would be to try to separate packages with binaries from repositories that contain tools and create a format "package_mytools" repository that is just responsible for installing the binary mytool. Hopefully this helps, -John On Tue, Dec 16, 2014 at 9:43 AM, KRESS Arnaud (ESP) <akress@unistra.fr> wrote:

Hi gentlemen, I am currently struggling to create a custom package (to share via a toolshed) that would include a tool definition file and the associated binary. Once installed, I can launch a job but I get the following error message:

mytool.sh: line 14: mytool: unknown command

It seems that the PATH was not correctly set. What am I doing wrong ?

My directory tree in my package: . ├── mytool.sh ├── mytool.xml ├── bin │ └── mytool └── tool_dependencies.xml

Here is my tool_dependencies.xml file content:

<?xml version="1.0"?> <tool_dependency> <package name="mytool" version="1.0"> <install version="1.0"> <actions> <action type="set_environment"> <environment_variable name="PATH" action="prepend_to">$INSTALL_DIR/bin</environment_variable> </action> </actions> </install> <readme> </readme> </package> </tool_dependency>

Thank you, AK ___________________________________________________________ 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/