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