You can decide to hide a module based on it's full name, short name or path to the module file. So yes.
Ward On 28-06-17 09:55, Alan O'Cais wrote: > So you're saying you can select to hide all modules called > Core/Compiler/MPI (in a HMNS) which you pick up > from $EB_GLOBAL_PREFIX/modules/all ? > > On 28 June 2017 at 09:46, Kenneth Hoste <[email protected] > <mailto:[email protected]>> wrote: > > Hi Davide & Miguel, > > With Lmod, there's another option: you can selective hide modules > from users, without breaking existing 'module load' commands, to > actively discourage them from using old installations for example. > > This can be done in various ways, e.g. by putting .modulerc files in > place, or by implementing the isVisible hook (cfr. Ward's hook > implementations at > https://github.com/TACC/Lmod/tree/master/contrib/more_hooks > <https://github.com/TACC/Lmod/tree/master/contrib/more_hooks>) > > > regards, > > Kenneth > > > On 28/06/2017 01:01, Miguel Costa wrote: >> Hello Davide, >> >> On 28 Jun 2017 02:43, "Vanzo, Davide" <[email protected] >> <mailto:[email protected]>> wrote: >> >> So, I gave it a try and it works fine. >> >> The only annoyance (since it is more a matter of style) is >> that once I add the $EB_GLOBAL_PREFIX/modules/all to the >> $MODULEPATH, Lmod output for "module avail" gets pretty crowded. >> >> >> I know what you mean :) >> >> I was simplifying, I don't actually expose modules/all to normal >> users by default (they can always add it later, either by changing >> MODULEPATH directly or running "module use ...") >> >> 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 >> >> This has allowed me to, for instance, "deprecate" toolchains that >> created problems in many of our applications (again, users can add >> them back manually) >> >> You call also use the ordering in MODULEPATH to put a desired >> group at the top or bottom of the output of "module avail" (it >> would be interesting if lmod had a customizable "module shortlist" >> command...) >> >> Don't know how all this changes if you're using HMNS (see Alan's >> message) >> >> Miguel >> >> >> >> >> -- >> Davide Vanzo, PhD >> Application Developer >> Advanced Computing Center for Research and Education (ACCRE) >> Vanderbilt University - Hill Center 201 >> (615)-875-9137 <tel:%28615%29%20875-9137> >> www.accre.vanderbilt.edu <http://www.accre.vanderbilt.edu> >> >> On Jun 27 2017, at 10:43 am, Vanzo, Davide >> <[email protected] >> <mailto:[email protected]>> wrote: >> >> Thank you all for the great suggestions! >> >> DV >> >> >> On Jun 27 2017, at 3:14 am, Miguel Dias Costa >> <[email protected] >> <mailto:[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/hpcugent/easybuild-framework/issues/2143 >>> >>> <https://github.com/hpcugent/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] <mailto:[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] >>> <mailto:[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.html?highlight=sourcepath#sourcepath >>> >>> <https://easybuild.readthedocs.io/en/latest/Configuration.html?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 <tel:+49%202461%20615213> >>> Fax: +49 2461 61 6656 <tel:+49%202461%20616656> >>> E-mail: [email protected] >>> <mailto:[email protected]> >>> WWW: http://www.fz-juelich.de/ias/jsc/EN >>> <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 >>> >>> ------------------------------------------------------------------------------------------------ >>> >>> ------------------------------------------------------------------------------------------------ >>> >> >> > > > > > -- > 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: [email protected] <mailto:[email protected]> > WWW: http://www.fz-juelich.de/ias/jsc/EN
