On Feb 15, 2013, at 11:14 AM, Peter Cock wrote:
On Fri, Feb 15, 2013 at 4:05 PM, Greg Von Kuster email@example.com wrote:
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 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 it.
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: