maybe it's easier to put a symlink to the bar executable in the bin directory
of Foo and then
point BAR_BIN simply there? I'm not sure where in the easyconfig to create the
symlink (a
postinstallopts doesn't exist..).
Cheers,
John
--
We are ISO 27001 certified and meet the high requirements for information
security.
| John Donners | Senior consultant | Compute | SURFsara | Science Park 140 |
1098 XG Amsterdam | Nederland |
T (31)6 19039023 | john.donn...@surfsara.nl | www.surfsara.nl |
Aanwezig op | ma | di | wo | do | vr
----- Original Message -----
From: "kenneth hoste" <kenneth.ho...@ugent.be>
To: "easybuild" <easybuild@lists.ugent.be>, "Caspar van Leeuwen"
<caspar.vanleeu...@surfsara.nl>
Sent: Monday, 8 January, 2018 20:10:58
Subject: Re: [easybuild] Use of EBROOT of a dependency as modextravar
On 08/01/2018 13:58, Caspar van Leeuwen wrote:
> I disagree, because the requirement that the variable 'BAR_BIN' that is set
> is a requirement from Foo, not a 'feature' from Bar. Bar knows absolutely
> nothing about this variable, and is very happy to run without it - thus it
> has no place in a Bar module. To illustrate that more: what if someone
> tomorrow develops a Foo2, which requires another environment variable
> 'WHERE_CAN_FOO2_FIND_BAR' to point to the Bar executable, would you reinstall
> Bar and put this additional variable also in the module file of Bar, just
> because Foo2 needs it?
>
> In my view, BAR_BIN, and WHERE_CAN_FOO2_FIND_BAR are things that are specific
> to Foo and Foo2 respectively, and should be set in their modules. The
> commonality is that I would want to use $EBROOTBAR - which is of course set
> by Bar -, to set BAR_BIN/WHERE_CAN_FOO2_FIND_BAR. I agree that this requires
> the additional assumption within the Foo module that the Bar module installs
> in the $EBROOTBAR/bin folder, which is not very nice. However, I think this
> is a far more generic assumption than when the Foo/Foo2 module has to assume
> that Bar sets BAR_BIN/WHERE_CAN_FOO2_FIND_BAR itself.
>
> Thus, while I understand the 'if it references the tree of Bar, it should be
> set by Bar' sentiment, I think that the alternative here (setting environment
> variables required by Foo, Foo2, or whichever package comes next, in the Bar
> module) is simply worse.
+1, $BAR_BIN should be defined by the Foo module, ideally, since it's a
runtime setting for Foo. But... (see below).
> So, my question remains: is it correct that I cannot access the EBROOT of
> dependencies from within modextravars? And is there an elegant way to achieve
> this?
The problem is not so much that $EBROOTBAR isn't defined when the module
is generated (it actually is), but that $EBROOTBAR is a construct not
known by Tcl or Lua module files.
EasyBuild does not resolve environment variables specfied through
modextravars, it just injects the values into the generated module file
(and then does a test-load to make sure the module works).
> My current, not-so-elegant way is:
>
> modextravars = {'BAR_BIN': '$::env(EBROOTBAR)/bin'}
>
> This works, but $::env (which reads EBROOTBAR at the time the module is
> loaded) is - as far as I know - specific for Tcl modules. Also, things like
> module disp Foo get messed up, because EBROOTBAR is not set then. Thus, I'm
> not very much in favor of this solution and looking for a way to have
> EasyBuild set the path for BAR_BIN at installation time.
You could use the modtclfooter/modluafooter easyconfig parameters to
inject the Tcl/Lua specific code to define $BAR_BIN, but then you still
how the problem about "module disp Foo".
A construct like this:
import os
modextravars = {'BAR_BIN': '%s/bin' % os.getenv('EBROOTBAR')}
will not work either, because the Bar dependency will not be loaded yet
when the easyconfig file is being parsed (how could it, EB doesn't know
what the dependencies are before it parses the easyconfig file...).
A (dirty) workaround for that could be to manually load the Bar module
first, and then ask EB to install Foo.
The real fix for this issue is to add support in EasyBuild to resolve an
environment variable whenever the string value containing it is used, so
you can do something like:
modextravars = {'BAR_BIN': '%(env:EBROOTBAR)s/bin'}
This basically boils down to enhancing the existing templating support
to pick up stuff from the environment and define the required %(env:...)
template values.
If this works, it has a downside too: the installation prefix of Bar
will be hardcoded in the Foo module (which is probably what Åke doesn't
like).
Another option is to include a modloadmsg to instruct the user to run
"export BAR_BIN=$EBROOTBAR/bin".
But then try you're moving the problem to explaining to your end users
why the module can't do that for them... ;-)
regards,
Kenneth
>
> Regards,
>
> Caspar
>
>
> ----- Original Message -----
> From: "Åke Sandgren" <ake.sandg...@hpc2n.umu.se>
> To: "Caspar van Leeuwen" <caspar.vanleeu...@surfsara.nl>
> Sent: Monday, 8 January, 2018 13:20:47
> Subject: Re: [easybuild] Use of EBROOT of a dependency as modextravar
>
> Any env variable that references the installation tree of Bar should be
> set in the module file for Bar!
>
> Foo can then use it. It just needs to depend on Bar.
>
> Foo should NOT set any env variables related to Bar!
>
> That is how modules are supposed to work.
>
> On 01/08/2018 01:17 PM, Caspar van Leeuwen wrote:
>> I'm sorry, maybe I should have clarified: Foo requires BAR_BIN to be
>> present /at runtime/, so yes, I really do want it to be set in the
>> module file of Foo. Foo provides a (GUI) wrapper for Bar, but it needs
>> to know the location of the Bar binary. Rather than searching the path -
>> as other programs might have done -, Foo uses the BAR_BIN environment
>> variable to locate and call Bar (in fact, the installation instructions
>> for Foo list that you have to set BAR_BIN).
>>
>> Regards,
>>
>> Caspar
>>
>> ------------------------------------------------------------------------
>> *From: *"Alan O'Cais" <a.oc...@fz-juelich.de>
>> *To: *"easybuild" <easybuild@lists.ugent.be>
>> *Sent: *Monday, 8 January, 2018 12:38:32
>> *Subject: *Re: [easybuild] Use of EBROOT of a dependency as modextravar
>>
>> I think you are misunderstanding the scope of modextravars, it is there
>> to set additional variables in the resultant module file from the
>> installation (it is not relevant to the install process of the software,
>> only the final module file that is written). The modextravars should be
>> set in the Bar easyconfig if you wish to leverage it in Foo? Otherwise
>> you just use something like
>>
>> preconfigopts = 'BAR_BIN=$EBROOTBAR/bin '
>>
>> in the Foo easyconfig.
>>
>> On 8 January 2018 at 12:29, Caspar van Leeuwen
>> <caspar.vanleeu...@surfsara.nl <mailto:caspar.vanleeu...@surfsara.nl>>
>> wrote:
>>
>> Dear EasyBuilders,
>>
>>
>> Question: I have a Package Foo that provides a wrapper for a
>> software package Bar. Thus, in the EasyConfig for Foo, I list Bar as
>> a dependency.
>>
>>
>> Now, Foo requires an environment variable BAR_BIN to be set that
>> points to the Bar binary. Thus, what I would like to do in the Foo
>> EasyConfig is something like:
>>
>>
>> modextravars = {‘BAR_BIN’: ‘$EBROOTBAR/bin’}
>>
>>
>> This doesn’t work: I get an error (something like ‘no variable
>> EBROOTBAR’). I presume the reason is that in the modextravars step
>> for 'Foo', the 'Bar' module isn’t actually loaded - thus EBROOTBAR
>> is not set.
>>
>>
>> I could use $root (which points to the FOO root, and //does exist
>> when modextravars is executed) and peal off the
>> …/Foo/(version)-(toolchain), then add .../Bar/(version)-(toolchain),
>> but this feels like a very dirty solution.
>>
>>
>> Does anyone know of an elegant way to achieve this? And just to
>> check: is it correct that the dependencies are not loaded when
>> modextravars is executed?
>>
>>
>> Best regards,
>>
>>
>> Caspar van Leeuwen
>>
>>
>>
>>
>> --
>> Dr. Alan O'Cais
>> E-CAM Software Manager
>> Juelich Supercomputing Centre
>> Forschungszentrum Juelich GmbH
>> 52425 Juelich, Germany
>>
>> Phone: +49 2461 61 5213
>> Fax: +49 2461 61 6656
>> E-mail: a.oc...@fz-juelich.de <mailto:a.oc...@fz-juelich.de>
>> WWW: http://www.fz-juelich.de/ias/jsc/EN
>>
>>
>> ------------------------------------------------------------------------------------------------
>> ------------------------------------------------------------------------------------------------
>> Forschungszentrum Juelich GmbH
>> 52425 Juelich
>> Sitz der Gesellschaft: Juelich
>> Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
>> Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
>> Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
>> Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
>> Prof. Dr. Sebastian M. Schmidt
>> ------------------------------------------------------------------------------------------------
>> ------------------------------------------------------------------------------------------------
>>
>>
