Create a package with binaries

classic Classic list List threaded Threaded
4 messages Options
AK
Reply | Threaded
Open this post in threaded view
|

Create a package with binaries

AK
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/
Reply | Threaded
Open this post in threaded view
|

Re: Create a package with binaries

John Chilton-4
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) <[hidden email]> 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/
___________________________________________________________
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/
AK
Reply | Threaded
Open this post in threaded view
|

Re: Create a package with binaries

AK
In reply to this post by AK
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 <[hidden email]> 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) <[hidden email]> 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/
 
 
___________________________________________________________
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/
Reply | Threaded
Open this post in threaded view
|

Re: Create a package with binaries

John Chilton-4
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) <[hidden email]> 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 <[hidden email]> 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) <[hidden email]> 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/
>
>
___________________________________________________________
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/