On Wed, Jun 28, 2017 at 7:01 AM, Miguel Costa <[email protected]>
wrote:

>
> Besides the module classes and hidden modules, what works for me is
> grouping the modules by toolchain (could this be added as a feature?) and
> exposing those groups separately
>
> (...)
>
> Don't know how all this changes if you're using HMNS
>

(realising I shouldn't have pushed HMNS to be back of my mind when I
started using EasyBuild)

so, it seems my grouping and default exposure of "toolchain module classes"
is equivalent, from the user perspective, to using HMNS and loading a
particular toolchain (up to the last level) by default (is it?)

If it is,

a) how hard is it to completely change MNS in an existing installation (at
least rebuild all modules, I suppose)

b) is anyone using MigrateFromEBToHMNS instead?

c) what can migrating to HMNS, in both cases, break? (at least easily
supporting local installations, if I understood Alan's message correctly)

Cheers,

Miguel



>
> Miguel
>
>
>
>
> --
> Davide Vanzo, PhD
> Application Developer
> Advanced Computing Center for Research and Education (ACCRE)
> Vanderbilt University - Hill Center 201
> (615)-875-9137 <(615)%20875-9137>
> www.accre.vanderbilt.edu
>
> On Jun 27 2017, at 10:43 am, Vanzo, Davide <[email protected]>
> wrote:
>
>> Thank you all for the great suggestions!
>>
>> DV
>>
>>
>> On Jun 27 2017, at 3:14 am, Miguel Dias Costa <[email protected]>
>> wrote:
>>
>>
>>
>> On 27/06/17 15:42, Alan O'Cais wrote:
>>
>> That is a neat trick with the sourcepaths that I will try out today.
>>
>>
>> I have to credit boegel, he told me about it, I had simply assumed that
>> would not work :)
>>
>>
>> I think there is a bit more to a user install space than what's been
>> mentioned when you have a HMNS, see https://github.com/hpcugen
>> t/easybuild-framework/issues/2143
>>
>>
>> ah... because there are then two roots to the hierarchy, the global one
>> and the local one?
>>
>> Miguel
>>
>>
>> On 27 June 2017 at 03:09, Fotis Georgatos <[email protected]> wrote:
>>
>>
>> Hi Miguel,
>>
>> Yeap! i’d also fully applause this approach, it is very similar to what
>> we’ve been doing since 2012!
>> - $MODULEPATH can include both global and local builds, you just need to
>> decide their exact order
>>   * fyi. recent versions of Lmod have in ./contrib a pair of use.own.eb
>> modulefiles, implementing the above
>> - the global install, is nothing more than by yet another user, which
>> just happens to be steered by admin
>> - i also encourage people to add a versionsuffix with their initials and
>> maybe a date, to keep things apart
>>
>> The trick with EASYBUILD_SOURCEPATH is quite nice, it could also be used
>> within use.own.eb/* modulefiles,
>> assuming that it is always *prepend*, as you described.
>>
>> F.
>>
>> On Jun 27, 2017, at 1:57 AM, Miguel Costa <[email protected]>
>> wrote:
>> > Hello Davide,
>> >
>> > I also had doubts initially because of what you mention and also using
>> global source paths, but this works for us:
>> >
>> > - create and manage a cluster-wide software stack with an easybuild
>> user, using EASYBUILD_PREFIX=$EB_GLOBAL_PREFIX
>> >
>> > - for normal users
>> >
>> >   - set EASYBUILD_PREFIX=$HOME/.local/easybuild but add
>> $EB_GLOBAL_PREFIX/modules/all to the $MODULEPATH (so that it finds the
>> already globally installed software)
>> >
>> >   - set 
>> > EASYBUILD_SOURCEPATH=$HOME/.local/easybuild/sources:$EB_GLOBAL_PREFIX/sources,
>> in this order (so that it downloads to local but looks in global). This was
>> recently clarified in the documentation, last line in
>> https://easybuild.readthedocs.io/en/latest/Configuration.htm
>> l?highlight=sourcepath#sourcepath
>> >
>> > I think this is enough.
>> >
>> > Miguel
>> >
>> > P.S. I encourage users to always add a versionsuffix in case they are
>> rebuilding a package that already exists globally, otherwise which one gets
>> picked depends on the order of the folders in $MODULEPATH
>>
>>
>> --
>> echo "sysadmin know better bash than english" | sed s/min/mins/ \
>>   | sed 's/better bash/bash better/' # signal detected in a CERN forum
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>> Dr. Alan O'Cais
>> E-CAM Software Manager
>> Juelich Supercomputing Centre
>> Forschungszentrum Juelich GmbH
>> 52425 Juelich, Germany
>>
>> Phone: +49 2461 61 5213 <+49%202461%20615213>
>> Fax: +49 2461 61 6656 <+49%202461%20616656>
>> E-mail: [email protected]
>> 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
>> ------------------------------------------------------------
>> ------------------------------------
>> ------------------------------------------------------------
>> ------------------------------------
>>
>>
>>
>

Reply via email to