Just been reading a bit more about the Galaxy packaging system.  Here's a 
slight modification to what I was suggesting that might fit in a bit better.  
Apologies for not being more familiar with the existing system before proposing 
extensions.

Recall that my goal is to support using a system-installed (native) package, at 
a defined version, which I aim to achieve by loading the appropriate 
environment module before running a tool.

We still have tool_dependencies.xml defining a package at a particular version, 
but rather than download and build the source code, there's just a directive 
that says how to pick up the correct program version at runtime, e.g. which 
environment module to load.

So instead of the tool_dependencies.xml fragment:
<tool_dependency>
    <package name="bwa" version="0.6.2">
        <install version="1.0">
            <actions>
                <action 
type="download_by_url">http://downloads.sourceforge.net/project/bio-bwa/bwa-0.6.2.tar.bz2</action>
                <action type="shell_command">make</action>
                <action type="move_file">
                    <source>bwa</source>
                    <destination>$INSTALL_DIR/bin</destination>
                </action>
                <action type="set_environment">
                    <environment_variable name="PATH" 
action="prepend_to">$INSTALL_DIR/bin</environment_variable>
                </action>
            </actions>
        </install>
    </package>
</tool_dependency>

We have something like this (NB: element and attribute names are for 
illustrative purposes only):

<tool_dependency>
    <package name="bwa" version="0.6.2">
        <use_native>
            <actions>
                <action type="module_load">bwa/0.6.2</action>
            </actions>
        </use_native>
    </package>
</tool_dependency>

This causes the right thing (module load bwa/0.6.2) to be stuck into the 
dependencies env.sh file when this package is installed from the toolshed.  We 
could call this toolshed tool native_package_bwa_0_6_2, to avoid confusion with 
the existing download-and-make one.

We might want a bit of flexibility on what actions are supported (in case we 
want to support Software Collections, for example).

What do you think?

cheers,
Simon

PS: In case it wasn't already clear, solving this problem well is quite 
important to us here at AgResearch.  ;-)


=======================================================================
Attention: The information contained in this message and/or attachments
from AgResearch Limited is intended only for the persons or entities
to which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipients is prohibited by AgResearch
Limited. If you have received this message in error, please notify the
sender immediately.
=======================================================================

___________________________________________________________
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/

To search Galaxy mailing lists use the unified search at:
  http://galaxyproject.org/search/mailinglists/

Reply via email to