Hello Peter, please see my response at the end.

On Feb 15, 2013, at 6:47 AM, Peter Cock wrote:

>>> On Sep 12, 2012, at 1:00 PM, David Hoover wrote:
>>> 
>>> Are there any environment variables that are honored by toolshed installed
>>> tools?  I tried creating a tool that uses ${GALAXY_DATA_INDEX_DIR} or
>>> $GALAXY_HOME, then uploaded it the test toolshed, then installed it
>>> automatically.  Neither of these resolved to what I expected.  I don't want
>>> to hard-code the path in the xml tool file, but rather have a default
>>> location for other executables and jar files.  How should this best be done?
>>> 
>>> David Hoover
>>> Helix Systems Staff
> 
> On Wed, Sep 12, 2012 at 6:15 PM, Greg Von Kuster <g...@bx.psu.edu> wrote:
>> Hello David,
>> 
>> This is not currently possible, but will be available in the next Galaxy
>> distribution release, currently scheduled for about 10 days from now.  You
>> will include a tool_dependencies.xml file in your tool shed repository that
>> looks something like the following.
>> 
>> <?xml version="1.0"?>
>> <tool_dependency>
>>    <set_environment version="1.0">
>>        <environment_variable name="JAVA_JAR_PATH"
>> action="set_to">$INSTALL_DIR</environment_variable>
>>    </set_environment>
>> </tool_dependency>
>> 
>> Your tool will find the required files via the defined JAVA_JAR_PATH by
>> using a <requirements> tag set in the tool config, something like this:
>> 
>>    <requirements>
>>        <requirement type="set_environment">JAVA_JAR_PATH </requirement>
>>    </requirements>
>> 
>> The <command> tag in the tool config would be something like this:
>> 
>> <command interpreter="python">
>> python_wrapper.py $JAVA_JAR_PATH/some_file.jar $param1 $param2...
>> </command>
>> 
>> I'm close to having this working, so if you are interested in testing before
>> the next Galaxy dist release, let me know and I'll tell you when the Galaxy
>> central repository has the new feature.
>> 
>> Thanks!
>> 
>> 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...
> 
> 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.

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?

What kinds of files would require knowledge of the GALAXY_HOME directory?

Thanks Peter,

Greg Von Kuster




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

Reply via email to