1:09 a.m.
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(a)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(a)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(a)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/