Hi All,
That's the idea.
An env.sh for each toolshed tool (or tool dependency). Everything is
generic and modular this way, while giving us better control over
versions, and control over compilation settings.

Here is something I've tried.
    <install version="1.0">
      <actions>
        <action type="set_environment">
          <environment_variable name="PATH"
action="prepend_to">$INSTALL_DIR/bin</environment_variable>
        </action>
      </actions>
    </install>

The tool installs but the tool dependency install fails.
I've tried variations by touching a file and moving it to
$INSTALL_DIR. But It only seems to work when I download and "make"
something (which I managed for meme_chip).
So I guess there is a lot of magic that I don't understand.

Ideally when I wrap a toolshed tool It can just generate a env.sh that
is tied to this specific revision (tool wrapper version) eg.
ffa8aaa14f7c
When a tool version changes and the wrapper changes a different env.sh
can be made and point to a different version of the tool.
iiwkerufh234f
All the while the admin can easily modify these without messily
creating his/her own env.sh's

At the moment we have everything as accessible through the command
line so it's impossible to separate different tool versions without
separate env.sh. But again it would be better for the toolshed tool to
create these rather than the admin.

Cheers,
Kevin.

On 13 November 2012 12:36, Derrick Lin <klin...@gmail.com> wrote:
> Hi Greg,
>
> I am wondering the similar thing. If I understand Kevin's post correctly, I
> think the question really is: if the automated tools build is the
> requirement for creating the shed tool version specific env.sh automatically
> during the shed tool installation.
>
> Take BWA on the Tool Shed as an example, during the installation, BWA binary
> was built on the fly and  the path
> "tool-dependency/bwa/0.5.9/devteam/bwa_wrappers/ffa8aaa14f7c/env.sh" was
> created.
>
> But in some cases, the automated tools build is not desirable. On the
> cluster that serves our Galaxy, we have had BWA compiled with the hardware
> optimized compiler, and I simply want to put existing BWA path to the env.sh
> without compiling another BWA that will not be used.
>
> So it makes sense (at least to me) that the shed tool installation always
> create the specific env.sh and provides the automated tools build as an
> option.
>
> Cheers,
> Derrick
>
>
>
> On Tue, Nov 13, 2012 at 8:21 AM, Greg Von Kuster <g...@bx.psu.edu> wrote:
>>
>> Hi Kevin,
>>
>> I'm not clear why you want to create a "dummy" env.sh file, so I may not
>> be able to answer your question.  However, see the following tool shed wiki
>> page in case you want to create an env.sh file that is sourced when the
>> tool(s) included in the installed repository is executed in the Galaxy
>> instance in case this is what you're looking for.
>>
>>
>> http://wiki.galaxyproject.org/ToolShedToolFeatures#Finding_dependencies_included_in_an_installed_repository_at_tool_execution_time
>>
>> Greg Von Kuster
>>
>>
>> On Nov 12, 2012, at 1:51 AM, Kevin Y wrote:
>>
>> > Hi dev list,
>> >
>> > What is the simplest xml I can put into a tool_dependencies.xml
>> > for it to create a dummy env.sh in tool-dependency/tool/version/
>> > ..../awef234243/env.sh
>> >
>> > And will this be sourced each time. Or does the dependency need to be
>> > some sort of "successfully install" status for it to be sourced?
>> >
>> > Ideally I would be elegant if there is a way to create this env.sh
>> > easily as it's the best way for a galaxy admin to manage the different
>> > versions of dependencies.
>> >
>> > Thanks,
>> > Kevin.
>> > ___________________________________________________________
>> > 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:
>>
>>   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:

  http://lists.bx.psu.edu/

Reply via email to