On Feb 15, 2013, at 11:14 AM, Peter Cock wrote:
On Fri, Feb 15, 2013 at 4:05 PM, Greg Von Kuster
>> 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...
> 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
> What kinds of files would require knowledge of the GALAXY_HOME
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 it.
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: