Hi Greg,

I'm right now in implementing a setup_perl_environment and stumbled
about a tricky problem (that is not only related to perl but also for
ruby, python and R).

The Problem:
Lets assume a perl package (A) requires a xml parser written in C/C++
(Z) is a dependency that I can import but as far as I can see there is
no way to call set_environment_for_install before
setup_perl_environment, because setup_perl_environment defines an
installation type.

I would like to discuss that issue to get a few ideas. I can think about
these solutions:

- hackish solution:
I can call
install_environment.add_env_shell_file_paths( action_dict[ 
'env_shell_file_paths' ] ) inside of the setup_*_environment path and remove it 
from action type afterwards

- import all env.sh variables from every (package) definition.
Regardless if set_environment_for_install is set or not. 
I must admit, I do not understand why set_environment_for_install is
actually needed. I think we can assume that if I specify a 

    <package name="R_3_0_1" version="3.0.1">
        <repository name="package_r_3_0_1" owner="iuc"
prior_installation_required="True" />

I want the ENV vars sourced. 
Furthermore, that can solve an other issue: Namely, the need of ENV vars
from a package definition in the same file. Lets imagine package P has
dependency D and you want to download compile both in one
tool_dependencies.xml file.
You can either do it in one <package> definition or you need to split
them up in 2 tool_dependencies.xml files, rigth?
Maybe we can just assume a strict order in a tool_dependencies.xml file,
where every ENV vars are sourced for the following one? Does that make

Any other ideas?
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:

To search Galaxy mailing lists use the unified search at:

Reply via email to