Hello Bjoern,

On Nov 5, 2013, at 12:13 PM, Bjoern Gruening <bjoern.gruen...@gmail.com> wrote:

> 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).
> (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.


The above is fairly difficult to understand - can you provide an actual xml 
recipe that provides some context?


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

Again, it's difficult to provide good feedback on the above approach without an 
example recipe.  However, your "hackish solution" term probably means it is not 
ideal.  ;)

> 
> - import all env.sh variables from every (package) definition. Regardless if 
> set_environment_for_install is set or not. 


I don't think the above approach would be ideal.  It seems that it could fairly 
easily create conflicting environment variables within a single installation, 
so the latest value for an environment variable may not be what is expected.


> 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" />
>     </package>
> 
> I want the ENV vars sourced. 

Hmmm…so you are saying that you want the be able to define the above <package> 
tag set inside of an <actions> tag set and have everything work?  I think this 
may cause problems because  I believe the <set_environment_for_install> tag set 
restricts activity to only the time when a dependent repository will be using 
the defined environment from the required repository in order to compile one or 
more of it's dependencies.  Eliminating this restriction may cause problems 
after compilation.  ALthough I cannot state this as a definite fact.

> 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 sense?

It may make sense, but without an example it's diffiecult to answer this for 
sure.  Can you provide some xml recipes that use your different proposals?

> 
> Any other ideas?

Not yet, but possibly after your next response.  ;)


> Thanks,
> Bjoern

Thanks!

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/

To search Galaxy mailing lists use the unified search at:
  http://galaxyproject.org/search/mailinglists/

Reply via email to