Hi Peter,

On Feb 15, 2013, at 11:14 AM, Peter Cock wrote:

> On Fri, Feb 15, 2013 at 4:05 PM, Greg Von Kuster <g...@bx.psu.edu> wrote:
>>> Hi guys,
>>> Reading the rest of the thread from December, Greg's new code did
>>> get checked in and should be working (I've not tried this yet).
>>> However, I can't help feeling that defining the two environment variables
>>> David suggested, $GALAXY_DATA_INDEX_DIR and/or $GALAXY_HOME,
>>> would cover the majority of use cases and be far simpler for tool authors
>>> to use. Am I overlooking something?
>>> Usecase: Tool comes with a simple datafile (e.g. defining a search motif,
>>> say motif.dat) which is used by a script (say motif.py) via a normal
>>> Galaxy tool XML file (say motif.xml).
>>> Perhaps I can just put my data file next to the script and XML file, in
>>> which case it is easy for the script to locate? But I assumed that
>>> Galaxy best practice would be to use the tool-data folder somehow...
>>> Thanks,
>>> Peter
>> The current implementation places your motif.dat data file in the
>> repository installation directory, and tools that are properly configured
>> to locate dependencies that are included in the repository contents
>> will find it. This approach allows for tool dependency discovery and
>> easy maintenance when uninstalling repositories as all contents are
>> kept where they were installed.  Tools that are properly configured
>> with <requirement> tags will find dependencies because the
>> associated env.sh file is sourced, providing the location of all
>> dependencies to the environment.
> Is there a documented example I should be reading? In this use case
> (without any explicit XML markup), can I assume/have the motif.dat
> file be installed in the same folder next to the motif.py script and tool
> defining motif.xml file?

This scenario uses a tool dependency that is included in the repository which 
is discussed in the following section of the tool shed wiki.  Using this 
approach a tool config (Cheetah template) would have to be configured with the 
proper <requirement> tag set and an associated <command> tag set that would 
ultimately have the path to the motif.py script and motif.dat file defined in 
the environment.  Of course, this assumes the motify.py script is not the tool 
executable itself.


>> If your motif.dat file is one that would be manually altered by the
>> Galaxy administrator over time, perhaps automatically moving it
>> to the GALAXY_DATA_INDEX_DIR is justified.  However, in this
>> case, uninstalling the repository would probably not uninstall the
>> motif.dat file.  Does this fit with what you are thinking?
> In this case no, I would not expect the motif.dat file to be edited.
> Does this mean GALAXY_DATA_INDEX_DIR and the galaxy
> tool-data folder are intended for 'configuration' files the local admin
> may need to edit, rather than static tool specific data file?

Not necessarily, but with the exception of sample .loc files included in the 
repository, repository contents should not generally be required to be moved 
outside of their installation directory.

>> What kinds of files would require knowledge of the GALAXY_HOME
>> directory?
> Knowing GALAXY_DATA_INDEX_DIR would probably cover most
> cases, so knowing GALAXY_HOME is probably not needed.

I believe that the current implementation supports locating all tool 
dependencies, whether included in the repository or 3-rd party, so I'm not sure 
introducing GALAXY_DATA_INDEX_DIR to the repository installation process will 
be beneficial.  I can be swayed, however, if I see justification for supporting 

> Regards,
> Peter
> ___________________________________________________________
> 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/

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:


Reply via email to