Yes, I think this is the current best practice pattern - where you would stick the first tool_dependencies.xml in a "Tool Dependency Definition" repository named package_ballast_1_0 and the the other tool_dependencies.xml file would just sit in the tool_dependencies.xml file corresponding to say an "unrestricted" repository called ballst with your tools. There are lots of examples of this pattern in the IUC repositories: https://github.com/galaxyproject/tools-iuc Hope this helps, -John On Wed, Jan 7, 2015 at 3:14 AM, KRESS Arnaud (ESP) <akress@unistra.fr> wrote:
If I create two distincts packages, what should I indicate as package name in the tool_dependencies.xml files ?
For example, a binary package:
<tool_dependency> <package name="ballast" version="1.0"> <install version="1.0"> <actions> <action type="download_by_url">http://myurl.com/...</action> <action type="move_file"> <source>ballast</source> <destination>$INSTALL_DIR/bin</destination> </action> <action type="chmod"><file mode="750">$INSTALL_DIR/bin/ballast</file></action> <action type="set_environment"> <environment_variable name="PATH" action="prepend_to">$INSTALL_DIR/bin</environment_variable> </action> </actions> </install> </package> </tool_dependency>
and its corresponding tool package:
<tool_dependency> <package name="ballast" version="1.0"> <repository name="package_ballast" owner="me" /> </package> </tool_dependency>
Should I set the same name ?
Thank you, AK
Le Lundi 5 Janvier 2015 20:23 CET, John Chilton <jmchilton@gmail.com> a écrit:
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/