modules-interest — Discussion forum for modules usage.

Re: [Modules] 30 years

[Paul FM / P. <pau...@gm...>]

Yes - modules are great.

Too bad many Linux Distributions haven't progressed past Modules-3.2.10

The change to pure tcl code was really nice (it makes it easy to use the same module tree - including the module command on several different OSes and versions) - and it solved some issues.

Considering that this project was basically dead in 2005 (and I think it didn't really get going again until 2015), it is wonderful that it is being supported and expanded to more shells.



--  On 7/2/2021 6:49 AM, Frank Thommen wrote:
> Yes, incredible.  I started using Modules 20+ years ago.  And even though I am using only the very basic functions I would not know how to deploy our software stack w/o Modules.
> 
> Thanks a lot for your work and your continued support when we are running into problems ;-)
> 
> Cheers, Frank
> 
> 
> 
> On 29.06.21 07:29, Xavier Delaruelle wrote:
>> Dear All,
>>
>> Modules turns 30 today: the original article "Modules: Providing a
>> Flexible User Environment" by John L. Furlani dates back to June 29,
>> 1991.
>>
>>  From the Sun era to the Linux port in the early 00 then the move to
>> the pure Tcl version in 2017. Many things done and yet to come.
>>
>> I would like to thanks all the the user community and all the
>> maintainers that have handled this wonderful project over the time.
>>
>> Happy birthday Modules!
>>
>> Xavier
>>

-- 
--------------------------------------------------------
The views and opinions expressed above are strictly
those of the author(s).  The content of this message has
not been reviewed nor approved by any entity whatsoever.
--------------------------------------------------------
Paul FM         Info: http://paulfm.com/~paulfm/
--------------------------------------------------------

Re: [Modules] 30 years

[Frank T. <f.t...@dk...>]

Yes, incredible.  I started using Modules 20+ years ago.  And even 
though I am using only the very basic functions I would not know how to 
deploy our software stack w/o Modules.

Thanks a lot for your work and your continued support when we are 
running into problems ;-)

Cheers, Frank



On 29.06.21 07:29, Xavier Delaruelle wrote:
> Dear All,
> 
> Modules turns 30 today: the original article "Modules: Providing a
> Flexible User Environment" by John L. Furlani dates back to June 29,
> 1991.
> 
>  From the Sun era to the Linux port in the early 00 then the move to
> the pure Tcl version in 2017. Many things done and yet to come.
> 
> I would like to thanks all the the user community and all the
> maintainers that have handled this wonderful project over the time.
> 
> Happy birthday Modules!
> 
> Xavier
> 
> 
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest
> 

Re: [Modules] Problem with Zsh and rcexpandparam option

[<Xav...@CE...>]

Le vendredi 02 juillet 2021 à 13:35 +0200, Götz Waschk a écrit :
> Hi everyone,
> 
> I have tested Alma Linux 8.4 (a RHEL clone) with environment-modules 
> 4.5.2-1.el8, but I have also tested 4.7.0. The initial setup of the 
> module command fails with this error:
> 
> /usr/share/Modules/init/zsh:37: no such file or directory: 
> eval/usr/bin/tclsh
> /usr/share/Modules/init/zsh:37: no such file or directory: 
> eval/usr/bin/tclsh
> 
> This is related to the zsh shell option rcexpandparam I have enabled in
> my profile:
>    setopt rcexpandparam
> If this option is unset, the error goes away and modules are loaded.
> 
> Regards,
> Götz Waschk

Hi Götz,

Thanks for this report. I have created an issue on GitHub for this bug
[1].

By commenting line 14 of /usr/share/Modules/init/zsh you should get a
valid workaround.

# define modules runtine quarantine configuration
#export MODULES_RUN_QUARANTINE='LD_LIBRARY_PATH LD_PRELOAD'

I will update the auto initialization mechanism of Modules for zsh
shell to take into account the rcexpandparam option. This will be fixed
in next release (4.8.0) that should be out in a week or two.

Regards,
Xavier

[1] https://github.com/cea-hpc/modules/issues/403

[Modules] Problem with Zsh and rcexpandparam option

[Götz W. <goe...@de...>]

Hi everyone,

I have tested Alma Linux 8.4 (a RHEL clone) with environment-modules 
4.5.2-1.el8, but I have also tested 4.7.0. The initial setup of the 
module command fails with this error:

/usr/share/Modules/init/zsh:37: no such file or directory: 
eval/usr/bin/tclsh
/usr/share/Modules/init/zsh:37: no such file or directory: 
eval/usr/bin/tclsh

This is related to the zsh shell option rcexpandparam I have enabled in 
my profile:
   setopt rcexpandparam
If this option is unset, the error goes away and modules are loaded.

Regards,
Götz Waschk

-- 
Götz Waschk                            ° Phone:  +49 33762 77169
Deutsches Elektronen-Synchrotron DESY  ° E-Mail: goe...@de...
Platanenallee 6
15738 Zeuthen Germany

[Modules] 30 years

[Xavier D. <xav...@gm...>]

Dear All,

Modules turns 30 today: the original article "Modules: Providing a
Flexible User Environment" by John L. Furlani dates back to June 29,
1991.

>From the Sun era to the Linux port in the early 00 then the move to
the pure Tcl version in 2017. Many things done and yet to come.

I would like to thanks all the the user community and all the
maintainers that have handled this wonderful project over the time.

Happy birthday Modules!

Xavier

Re: [Modules] module dependencies question :: sort of provides

[Bloecker, M. <Mar...@am...>]

Hello Eric,

One thing I forgot to point out: The approach described below requires the module auto-loading to be switched on. This can be done in multiple ways:

1. ./configure --enable-auto-handling during installation,
2. Setting environment variable MODULES_AUTO_HANDLING 1 , or
3. Using the --auto command line switch to the module command.

Regards,

Martin

-----Original Message-----
From: Bloecker, Martin <Mar...@am...> 
Sent: Donnerstag, 17. Juni 2021 12:56
To: Environment Modules usage and discussion. <mod...@li...>
Subject: Re: [Modules] module dependencies question :: sort of provides

Hello Eric,

I think one way to achieve what you want is for your 'foo' module to be dependent on a generic e.g. 'java8' module (i.e. prereq java8) rather than the explicit 'java/1.8.0'. This generic 'java8' module would then need to be dependent on either the 'java/1.8.0' or the 'graalvm-ce/java8-20.0.0' module to be loaded (i.e. prereq java/1.8.0 graalvm-ce/java8-20.0).

With this setup

module load foo

should result in the modules 'java/1.8.0', 'java8' and 'foo' to be loaded, while a

module load graalvm-ce/java8-20.0.0 foo

should result in the modules 'graalvm-ce/java8-20.0.0', 'java8' and 'foo' to be loaded.

Regards,

Martin

-----Original Message-----
From: Eric Deveaud <ede...@pa...> 
Sent: Donnerstag, 17. Juni 2021 12:38
To: mod...@li...
Subject: [Modules] module dependencies question :: sort of provides


Hello


we have some tools that relies on java.

we have installed various java flavours:
java/1.7.0
java/1.8.0
java/13.0.2
graalvm-ce/java8-20.0.0
graalvm-ce/java11-20.0.0


some user prefers to run with one of the java flavour installed, some with other one


is there a way to have a modulefile describing a dependency to let's say JAVA that will be satisfied when one of the java//graalvm-ce module is loaded ?

for exemple currently we have chosen that module foo depends on java/1.8.0 so one wnating to run module foo with graallvm-ce/8 will have to do te following

module load java/1.8.0 foo
module swich -f java/1.8.0 graalvm-ce/java8-20.0.0

     best regards

     Eric



_______________________________________________
Modules-interest mailing list
Mod...@li...
https://lists.sourceforge.net/lists/listinfo/modules-interest

_______________________________________________
Modules-interest mailing list
Mod...@li...
https://lists.sourceforge.net/lists/listinfo/modules-interest

Re: [Modules] module dependencies question :: sort of provides

[Bloecker, M. <Mar...@am...>]

Hello Eric,

I think one way to achieve what you want is for your 'foo' module to be dependent on a generic e.g. 'java8' module (i.e. prereq java8) rather than the explicit 'java/1.8.0'. This generic 'java8' module would then need to be dependent on either the 'java/1.8.0' or the 'graalvm-ce/java8-20.0.0' module to be loaded (i.e. prereq java/1.8.0 graalvm-ce/java8-20.0).

With this setup

module load foo

should result in the modules 'java/1.8.0', 'java8' and 'foo' to be loaded, while a

module load graalvm-ce/java8-20.0.0 foo

should result in the modules 'graalvm-ce/java8-20.0.0', 'java8' and 'foo' to be loaded.

Regards,

Martin

-----Original Message-----
From: Eric Deveaud <ede...@pa...> 
Sent: Donnerstag, 17. Juni 2021 12:38
To: mod...@li...
Subject: [Modules] module dependencies question :: sort of provides


Hello


we have some tools that relies on java.

we have installed various java flavours:
java/1.7.0
java/1.8.0
java/13.0.2
graalvm-ce/java8-20.0.0
graalvm-ce/java11-20.0.0


some user prefers to run with one of the java flavour installed, some with other one


is there a way to have a modulefile describing a dependency to let's say JAVA that will be satisfied when one of the java//graalvm-ce module is loaded ?

for exemple currently we have chosen that module foo depends on java/1.8.0 so one wnating to run module foo with graallvm-ce/8 will have to do te following

module load java/1.8.0 foo
module swich -f java/1.8.0 graalvm-ce/java8-20.0.0

     best regards

     Eric



_______________________________________________
Modules-interest mailing list
Mod...@li...
https://lists.sourceforge.net/lists/listinfo/modules-interest

[Modules] module dependencies question :: sort of provides

[Eric D. <ede...@pa...>]

Hello


we have some tools that relies on java.

we have installed various java flavours:
java/1.7.0
java/1.8.0
java/13.0.2
graalvm-ce/java8-20.0.0
graalvm-ce/java11-20.0.0


some user prefers to run with one of the java flavour installed, some 
with other one


is there a way to have a modulefile describing a dependency to let's say 
JAVA that will be satisfied when one of the java//graalvm-ce module is 
loaded ?

for exemple currently we have chosen that module foo depends on java/1.8.0
so one wnating to run module foo with graallvm-ce/8 will have to do te 
following

module load java/1.8.0 foo
module swich -f java/1.8.0 graalvm-ce/java8-20.0.0

     best regards

     Eric

[Modules] Editing modulefiles

[Xavier D. <xav...@gm...>]

Dear All,

New feature highlight for next release (4.8): the 'edit' sub-command
will give the ability to open existing modulefiles in a text editor.

More details and example at
https://modules.readthedocs.io/en/latest/MIGRATING.html#editing-modulefiles

Regards,
Xavier

Re: [Modules] Verbosity levels

[Xavier D. <xav...@gm...>]

Verbosity configuration is either a global site configuration or left
to the user choice (with the command-line options and shell startup
files).

The only possibility left in the scenario you describe is to hide the
module when loading and when it is loaded

Let's say there is a `foo` module which is a requirement of `bar`.
Load/unload of `foo` can be hidden with the module-hide command placed
for instance in the .modulerc file located in the `foo` directory:

#%Module
module-hide --hidden-loaded foo

As a consequence, foo module is also not reported from the loaded module list.

Regards,
Xavier

Le lun. 7 juin 2021 à 05:43, Michael Strelnikov
<mic...@gm...> a écrit :
>
> I'm not sure I understand how it works.
> My goal is to "concise" the verbosity level temporary within a single module only.
> I don't want to play with users' files and I don't have permissions for the global files too.
>
> On Fri, 4 Jun 2021 at 21:14, Xavier Delaruelle <xav...@gm...> wrote:
>>
>> By using the "concise" verbosity level, it will suppress the
>> informational messages which includes the "loading requirements"
>> messages but error and warning messages are still produced.
>>
>> If you want to hide one specific module, maybe you could be interested
>> by the "module-hide --hidden-loaded" modulerc command that hides a
>> given module once it is loaded: this module does not appear on "module
>> list" output (unless applying the -a/--all command-line option) and
>> the loading/unloading messages regarding this module are also
>> silenced. See one use case scenario in the cookbook:
>>
>> https://modules.readthedocs.io/en/latest/cookbook/hide-and-forbid-modules.html#limiting-view-to-the-useful-software-only
>>
>> Regards,
>> Xavier
>>
>> Le ven. 4 juin 2021 à 09:26, Michael Strelnikov
>> <mic...@gm...> a écrit :
>> >
>> > Thanks. Can it be done from a module itself and valid for loading module only? I don't want to silence all modules.
>> >
>> > On Fri, 4 Jun 2021 at 16:12, Xavier Delaruelle <xav...@gm...> wrote:
>> >>
>> >> Hello Michael,
>> >>
>> >> You could play with the "verbosity" option [1] to tune verbosity
>> >> level. "concise" or "silent" levels will suppress the automated module
>> >> handling messages.
>> >>
>> >> $ module config verbosity
>> >> ...
>> >> - Config. name ---------.- Value (set by if default overridden) ---------------
>> >> verbosity                 normal
>> >> $ module load bar
>> >> Loading bar/1
>> >>   Loading requirement: foo/1
>> >> $ module list
>> >> Currently Loaded Modulefiles:
>> >>  1) foo/1   2) bar/1
>> >> $ module purge
>> >> $ module config verbosity concise
>> >> $ module list
>> >> No Modulefiles Currently Loaded.
>> >> $ module load bar
>> >> $ module list
>> >> Currently Loaded Modulefiles:
>> >>  1) foo/1   2) bar/1
>> >>
>> >> Regards,
>> >> Xavier
>> >>
>> >> [1] https://modules.readthedocs.io/en/latest/module.html#mconfig-verbosity
>> >>
>> >> Le ven. 4 juin 2021 à 06:32, Michael Strelnikov
>> >> <mic...@gm...> a écrit :
>> >> >
>> >> > Hello,
>> >> >
>> >> >    I have a module that loads additional modules as part of the process. While doing that the user sees a message like "Loading requirement:".
>> >> >    Is there a way to hide this message?
>> >> >
>> >> > Thanks.
>> >> > _______________________________________________
>> >> > Modules-interest mailing list
>> >> > Mod...@li...
>> >> > https://lists.sourceforge.net/lists/listinfo/modules-interest
>> >>
>> >>
>> >> _______________________________________________
>> >> Modules-interest mailing list
>> >> Mod...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/modules-interest
>> >
>> > _______________________________________________
>> > Modules-interest mailing list
>> > Mod...@li...
>> > https://lists.sourceforge.net/lists/listinfo/modules-interest
>>
>>
>> _______________________________________________
>> Modules-interest mailing list
>> Mod...@li...
>> https://lists.sourceforge.net/lists/listinfo/modules-interest
>
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest

Re: [Modules] Verbosity levels

[Michael S. <mic...@gm...>]

I'm not sure I understand how it works.
My goal is to "concise" the verbosity level temporary within a single
module only.
I don't want to play with users' files and I don't have permissions for the
global files too.

On Fri, 4 Jun 2021 at 21:14, Xavier Delaruelle <xav...@gm...>
wrote:

> By using the "concise" verbosity level, it will suppress the
> informational messages which includes the "loading requirements"
> messages but error and warning messages are still produced.
>
> If you want to hide one specific module, maybe you could be interested
> by the "module-hide --hidden-loaded" modulerc command that hides a
> given module once it is loaded: this module does not appear on "module
> list" output (unless applying the -a/--all command-line option) and
> the loading/unloading messages regarding this module are also
> silenced. See one use case scenario in the cookbook:
>
>
> https://modules.readthedocs.io/en/latest/cookbook/hide-and-forbid-modules.html#limiting-view-to-the-useful-software-only
>
> Regards,
> Xavier
>
> Le ven. 4 juin 2021 à 09:26, Michael Strelnikov
> <mic...@gm...> a écrit :
> >
> > Thanks. Can it be done from a module itself and valid for loading module
> only? I don't want to silence all modules.
> >
> > On Fri, 4 Jun 2021 at 16:12, Xavier Delaruelle <
> xav...@gm...> wrote:
> >>
> >> Hello Michael,
> >>
> >> You could play with the "verbosity" option [1] to tune verbosity
> >> level. "concise" or "silent" levels will suppress the automated module
> >> handling messages.
> >>
> >> $ module config verbosity
> >> ...
> >> - Config. name ---------.- Value (set by if default overridden)
> ---------------
> >> verbosity                 normal
> >> $ module load bar
> >> Loading bar/1
> >>   Loading requirement: foo/1
> >> $ module list
> >> Currently Loaded Modulefiles:
> >>  1) foo/1   2) bar/1
> >> $ module purge
> >> $ module config verbosity concise
> >> $ module list
> >> No Modulefiles Currently Loaded.
> >> $ module load bar
> >> $ module list
> >> Currently Loaded Modulefiles:
> >>  1) foo/1   2) bar/1
> >>
> >> Regards,
> >> Xavier
> >>
> >> [1]
> https://modules.readthedocs.io/en/latest/module.html#mconfig-verbosity
> >>
> >> Le ven. 4 juin 2021 à 06:32, Michael Strelnikov
> >> <mic...@gm...> a écrit :
> >> >
> >> > Hello,
> >> >
> >> >    I have a module that loads additional modules as part of the
> process. While doing that the user sees a message like "Loading
> requirement:".
> >> >    Is there a way to hide this message?
> >> >
> >> > Thanks.
> >> > _______________________________________________
> >> > Modules-interest mailing list
> >> > Mod...@li...
> >> > https://lists.sourceforge.net/lists/listinfo/modules-interest
> >>
> >>
> >> _______________________________________________
> >> Modules-interest mailing list
> >> Mod...@li...
> >> https://lists.sourceforge.net/lists/listinfo/modules-interest
> >
> > _______________________________________________
> > Modules-interest mailing list
> > Mod...@li...
> > https://lists.sourceforge.net/lists/listinfo/modules-interest
>
>
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest
>

Re: [Modules] Verbosity levels

[Xavier D. <xav...@gm...>]

By using the "concise" verbosity level, it will suppress the
informational messages which includes the "loading requirements"
messages but error and warning messages are still produced.

If you want to hide one specific module, maybe you could be interested
by the "module-hide --hidden-loaded" modulerc command that hides a
given module once it is loaded: this module does not appear on "module
list" output (unless applying the -a/--all command-line option) and
the loading/unloading messages regarding this module are also
silenced. See one use case scenario in the cookbook:

https://modules.readthedocs.io/en/latest/cookbook/hide-and-forbid-modules.html#limiting-view-to-the-useful-software-only

Regards,
Xavier

Le ven. 4 juin 2021 à 09:26, Michael Strelnikov
<mic...@gm...> a écrit :
>
> Thanks. Can it be done from a module itself and valid for loading module only? I don't want to silence all modules.
>
> On Fri, 4 Jun 2021 at 16:12, Xavier Delaruelle <xav...@gm...> wrote:
>>
>> Hello Michael,
>>
>> You could play with the "verbosity" option [1] to tune verbosity
>> level. "concise" or "silent" levels will suppress the automated module
>> handling messages.
>>
>> $ module config verbosity
>> ...
>> - Config. name ---------.- Value (set by if default overridden) ---------------
>> verbosity                 normal
>> $ module load bar
>> Loading bar/1
>>   Loading requirement: foo/1
>> $ module list
>> Currently Loaded Modulefiles:
>>  1) foo/1   2) bar/1
>> $ module purge
>> $ module config verbosity concise
>> $ module list
>> No Modulefiles Currently Loaded.
>> $ module load bar
>> $ module list
>> Currently Loaded Modulefiles:
>>  1) foo/1   2) bar/1
>>
>> Regards,
>> Xavier
>>
>> [1] https://modules.readthedocs.io/en/latest/module.html#mconfig-verbosity
>>
>> Le ven. 4 juin 2021 à 06:32, Michael Strelnikov
>> <mic...@gm...> a écrit :
>> >
>> > Hello,
>> >
>> >    I have a module that loads additional modules as part of the process. While doing that the user sees a message like "Loading requirement:".
>> >    Is there a way to hide this message?
>> >
>> > Thanks.
>> > _______________________________________________
>> > Modules-interest mailing list
>> > Mod...@li...
>> > https://lists.sourceforge.net/lists/listinfo/modules-interest
>>
>>
>> _______________________________________________
>> Modules-interest mailing list
>> Mod...@li...
>> https://lists.sourceforge.net/lists/listinfo/modules-interest
>
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest

Re: [Modules] Verbosity levels

[Michael S. <mic...@gm...>]

Thanks. Can it be done from a module itself and valid for loading module
only? I don't want to silence all modules.

On Fri, 4 Jun 2021 at 16:12, Xavier Delaruelle <xav...@gm...>
wrote:

> Hello Michael,
>
> You could play with the "verbosity" option [1] to tune verbosity
> level. "concise" or "silent" levels will suppress the automated module
> handling messages.
>
> $ module config verbosity
> ...
> - Config. name ---------.- Value (set by if default overridden)
> ---------------
> verbosity                 normal
> $ module load bar
> Loading bar/1
>   Loading requirement: foo/1
> $ module list
> Currently Loaded Modulefiles:
>  1) foo/1   2) bar/1
> $ module purge
> $ module config verbosity concise
> $ module list
> No Modulefiles Currently Loaded.
> $ module load bar
> $ module list
> Currently Loaded Modulefiles:
>  1) foo/1   2) bar/1
>
> Regards,
> Xavier
>
> [1] https://modules.readthedocs.io/en/latest/module.html#mconfig-verbosity
>
> Le ven. 4 juin 2021 à 06:32, Michael Strelnikov
> <mic...@gm...> a écrit :
> >
> > Hello,
> >
> >    I have a module that loads additional modules as part of the process.
> While doing that the user sees a message like "Loading requirement:".
> >    Is there a way to hide this message?
> >
> > Thanks.
> > _______________________________________________
> > Modules-interest mailing list
> > Mod...@li...
> > https://lists.sourceforge.net/lists/listinfo/modules-interest
>
>
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest
>

Re: [Modules] Verbosity levels

[Xavier D. <xav...@gm...>]

Hello Michael,

You could play with the "verbosity" option [1] to tune verbosity
level. "concise" or "silent" levels will suppress the automated module
handling messages.

$ module config verbosity
...
- Config. name ---------.- Value (set by if default overridden) ---------------
verbosity                 normal
$ module load bar
Loading bar/1
  Loading requirement: foo/1
$ module list
Currently Loaded Modulefiles:
 1) foo/1   2) bar/1
$ module purge
$ module config verbosity concise
$ module list
No Modulefiles Currently Loaded.
$ module load bar
$ module list
Currently Loaded Modulefiles:
 1) foo/1   2) bar/1

Regards,
Xavier

[1] https://modules.readthedocs.io/en/latest/module.html#mconfig-verbosity

Le ven. 4 juin 2021 à 06:32, Michael Strelnikov
<mic...@gm...> a écrit :
>
> Hello,
>
>    I have a module that loads additional modules as part of the process. While doing that the user sees a message like "Loading requirement:".
>    Is there a way to hide this message?
>
> Thanks.
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest

Re: [Modules] Using module-hide/forbid inside a modulefile

[Xavier D. <xav...@gm...>]

Le jeu. 3 juin 2021 à 11:43, Nick Papior <nic...@gm...> a écrit :
>
> Dear Xavier,
>
> Our current use case is for instance maintaining several python installations (3.8, 3.9, ...)
> Each has to have a numpy for each version, and so on and so forth. :)
>
> This could of course be solved in various ways:
>
> A) only expose python/3.8  python/3.9 and when they get loaded prepend a MODULEPATH to the search path such that only modules are visible for that python version. This I think is the cleanest way.
>
> B) expose all of them with sufficiently distinct names and hide/unhide them based on which python/X is loaded. In the current case one should put this logic in the rc file which easily gets extremely bloated with lots of if [is-loaded python/3.8 ] ... else if [is loaded python/3.9 ] etc.
> Enabling hiding stuff on a per module basis would ease these things and give power to the people. ;)
> Additionally users could them-selves hide stuff they don't want to see. E.g. I never use R, so I could hide all R packages ;)
> Generally, I find that users will generally not do this unless they are "power" users. And they already know how to do stuff, so one shouldn't worry. :)
>
> Let me know if I haven't explained this good enough. :)

Dear Nick,

That's a lot more clear now, thanks.

With current module version there is no better than the solution
described by Michael or having modulerc files checking the version
loaded of python and applying specific hiding rules based on that.

Hide/forbid mechanism only works from the rc files as they are the
only files evaluated when resolving available modules. An idea could
be to add when loading a module additional hide/forbid rules that
would be set in the loaded environment to apply for the next "module
avail" calls in addition to the rules set in modulerc files.

I am currently working on a "variant" mechanism to define flavors of
modules when loading them. It will help to precise the specific build
to load of a module. Following you example, we could imagine that
"module load numpy/1.16 python=3.8" will load the numpy version 1.16
built for python3.8 and load this python module as a requirement. I
think this mechanism (available starting version 4.8 that will be
released this summer) could help for what you would like to do.

> Additionally users could them-selves hide stuff they don't want to see. E.g. I never use R, so I could hide all R packages ;)

Users are able to add their own "hide/forbid" rules, with the
`$HOME/.modulerc` file: they can define the module-hide/module-forbid
rules they want in this rc file if they want to limit the number of
modules they view.

Regards,
Xavier

[Modules] Verbosity levels

[Michael S. <mic...@gm...>]

Hello,

   I have a module that loads additional modules as part of the process.
While doing that the user sees a message like "Loading requirement:".
   Is there a way to hide this message?

Thanks.

Re: [Modules] Using module-hide/forbid inside a modulefile

[Sternberg, M. G. <ste...@an...>]

Mark,

You may also want to consider "module {use|unuse} <TOPDIR>" [1]. This has been the conventional mechanism to deploy a subset of modulefiles conditionally by some criterion (platform, OS type, version, …), prior to Xavier having created the much more fine-grained module-hide/-forbid mechanisms. The use/unuse mechanism marks the affected modulefiles on the file system level rather than by module-internal means. This can be administratively helpful long-term.

The use/unuse mechanism requires to place or break out the affected modulefiles into their own toplevel directory hierarchy [2]. Then, as part of Modulecmd startup [3], have module use/unuse subcommands be run in an all-common rc file or, less optimally, on the level of overarching shells [4] (caveat: plural, can thus be treacherous).


With best regards,
Michael


[1] https://modules.readthedocs.io/en/latest/module.html#subcmd-unuse

[2] By extension, you could conceivably have modulefiles by the same name in different TOPDIRs, thus deploying platform-specific (polymorphic) variants.

[3] https://modules.readthedocs.io/en/latest/module.html#modulecmd-startup 

[4] https://modules.readthedocs.io/en/latest/INSTALL.html#configuration


> On Jun 2, 2021, at 07:51, Mark Waterhouse <mar...@pc...> wrote:
> …
> I recently deployed a new Debian based OS and found that our standard tool installations ‘break’ modules.
> LD_LIBRARY_PATH is changed and tcl on Debian doesn’t like this.
> I started to look for a solution to this but then realized that the tool in question was not supported on Debian so even had I resolved the LD_LIBRARY_PATH issue, I would be no closer.
> … 
> I then came across module-hide and decided that this would be a better idea.
> I could load a ‘common’ module which, based on the OS, I could forbid access to these tools on operating systems where the tool was not supported.
> It looks like module-hide / module-forbid are only available in .modulerc and this led to my posting.

Re: [Modules] Using module-hide/forbid inside a modulefile

[<Xav...@CE...>]

Hi Mark,

Perfect!

Indeed, I should have written "file exists" or "file isfile" instead of "file stat" in my answer yesterday :-).

Regards,
Xavier


Le jeudi 03 juin 2021 à 08:58 +0000, Mark Waterhouse a écrit :
Hi Xavier

I tried your suggestion and got this error

Module ERROR: wrong # args: should be "file stat name varName"

      while executing

  "file stat /usr/lib/os-release"

      invoked from within

  "if {[file stat /usr/lib/os-release]} {

    puts stderr "Loading...."

  }"

However, I was able to follow your idea and found that this does exactly what I needed

if {[file isfile /usr/lib/os-release]} {

  module-forbid vendor/X

  module-hide vendor/X

}

For future readers, the only other thing I had to do was to change the syntax slightly….I hadn’t realised that /usr/lib/os-release exists on CentOS machines as well so am looking for the existence of /etc/debian-version instead.

I also then modified a number of my other module files to test whether a module is available prior to loading. This means that I don’t have to change too much of the environment

if {[is-avail vendor/X]} {module load vendor/X}

Thank you very much for your help and guidance Xavier
Mark

From: Xavier Delaruelle <xav...@gm...>
Reply to: "Environment Modules usage and discussion." <mod...@li...>
Date: Wednesday, 2 June 2021 at 19:25
To: "Environment Modules usage and discussion." <mod...@li...>
Subject: Re: [Modules] Using module-hide/forbid inside a modulefile

CAUTION: This email originated from outside of Palma Ceia SemiDesign. Links or attachments may be unsafe.

Le mer. 2 juin 2021 à 14:50, Mark Waterhouse <mar...@pc...<mailto:mar...@pc...>> a écrit :
Hi list

I have a common set of applications which are loaded as part of a default environment setup.
Today, most of our machines are using a RedHat/CentOS base and the modulefiles we have all work fine.

We have a standard set of tools which are loaded into the environment and some of these require modification to LD_LIBRARY_PATH.

I recently deployed a new Debian based OS and found that our standard tool installations ‘break’ modules.
LD_LIBRARY_PATH is changed and tcl on Debian doesn’t like this.
I started to look for a solution to this but then realized that the tool in question was not supported on Debian so even had I resolved the LD_LIBRARY_PATH issue, I would be no closer.


I was reading through the cookbook (https://modules.readthedocs.io/en/latest/cookbook.html) to see if there were some good examples and realized I could do this by testing for the existence of a file (/usr/lib/os-release) and, if this didn’t exist, I could ignore the rest of the code.

I then came across module-hide and decided that this would be a better idea.
I could load a ‘common’ module which, based on the OS, I could forbid access to these tools on operating systems where the tool was not supported.
It looks like module-hide / module-forbid are only available in .modulerc and this led to my posting.


Is it possible to do something like this (module-forbid is the bit that I’m stumped on)
#%Module 1.0
#

# Some OS configurations are not supported for some tools
#  Debian
# For these hosts, we will hide all of the tools from Vendor X
setenv DEBHOST /usr/lib/os-release

set cmd { open [getenv DEBHOST] r }
if { ! [catch $cmd errmsg] } {
  module-forbid vendor/X/*
  module-hide vendor/X/*
}

I tried this and I get no error but the vendor modules still exist.
I wondered whether I could put some logic inside the .modulerc file but this would require changing all of my existing modulefiles; if I could work out the correct syntax for module-forbid/module-hide, I wouldn’t need to 😊


Does anyone have any suggestions?

Thanks in advance
Mark

Hi Mark,

You are close: to select all version of module vendor/X (let's says vendor/X/1.0, vendor/X/2.0), you just have to write:

module-forbid vendor/X
module-hide vendor/X

The extra * is taken literally by modules (which meant only the modulefile named vendor/X/* were set hidden and forbidden).

You could also simplify your OS-specific test condition:

if {[file stat /usr/lib/os-release]} {
    module-forbid vendor/X
    module-hide vendor/X
}

On a side note, if your LD_LIBRARY_PATH issue impacts the module command itself, you may look at the quarantine mechanism to protect module execution [1].

Regards,
Xavier

[1] https://modules.readthedocs.io/en/latest/MIGRATING.html#quarantine-mechanism-to-protect-module-execution
_______________________________________________
Modules-interest mailing list
Mod...@li...<mailto:Mod...@li...>
https://lists.sourceforge.net/lists/listinfo/modules-interest

Re: [Modules] Using module-hide/forbid inside a modulefile

[Nick P. <nic...@gm...>]

Dear Xavier,

Our current use case is for instance maintaining several python
installations (3.8, 3.9, ...)
Each has to have a numpy for each version, and so on and so forth. :)

This could of course be solved in various ways:

A) only expose python/3.8  python/3.9 and when they get loaded prepend a
MODULEPATH to the search path such that only modules are visible for that
python version. This I think is the cleanest way.

B) expose all of them with sufficiently distinct names and hide/unhide them
based on which python/X is loaded. In the current case one should put this
logic in the rc file which easily gets extremely bloated with lots of if
[is-loaded python/3.8 ] ... else if [is loaded python/3.9 ] etc.
Enabling hiding stuff on a per module basis would ease these things and
give power to the people. ;)
Additionally users could them-selves hide stuff they don't want to see.
E.g. I never use R, so I could hide all R packages ;)
Generally, I find that users will generally not do this unless they are
"power" users. And they already know how to do stuff, so one shouldn't
worry. :)

Let me know if I haven't explained this good enough. :)

Den ons. 2. jun. 2021 kl. 20.36 skrev Xavier Delaruelle <
xav...@gm...>:

> Hi Nick,
>
> Le mer. 2 juin 2021 à 15:13, Nick Papior <nic...@gm...> a écrit :
>
>> I agree, this would be nice.
>>
>> Had this on my todo to bring this to the board as well.
>> On another note:
>> - it would be nice if one could "module-unhide" in module files as well
>>
>
> module-hide is primarily made for site admins to enforce module hiding for
> their users. Unhiding previously hidden modules is currently not in the
> development roadmap, as it would break the setup made by the admins. I
> would recommend to avoid hiding modules if some conditions are not met (or
> to hide modules only if some conditions are met) rather trying to unhide
> modules after hiding them.
>
>
>> - it would be nice if one could change the defaults in module files as
>> well so users don't accidentally unload something intended and reload
>> something else.
>>
>
> Could you elaborate a bit more on this use case. I do not get it.
>
> Regards,
> Xavier
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest
>


-- 
Kind regards Nick

Re: [Modules] Using module-hide/forbid inside a modulefile

[Mark W. <mar...@pc...>]

Hi Xavier

I tried your suggestion and got this error

Module ERROR: wrong # args: should be "file stat name varName"

      while executing

  "file stat /usr/lib/os-release"

      invoked from within

  "if {[file stat /usr/lib/os-release]} {

    puts stderr "Loading...."

  }"

However, I was able to follow your idea and found that this does exactly what I needed

if {[file isfile /usr/lib/os-release]} {

  module-forbid vendor/X

  module-hide vendor/X

}

For future readers, the only other thing I had to do was to change the syntax slightly….I hadn’t realised that /usr/lib/os-release exists on CentOS machines as well so am looking for the existence of /etc/debian-version instead.

I also then modified a number of my other module files to test whether a module is available prior to loading. This means that I don’t have to change too much of the environment

if {[is-avail vendor/X]} {module load vendor/X}

Thank you very much for your help and guidance Xavier
Mark

From: Xavier Delaruelle <xav...@gm...>
Reply to: "Environment Modules usage and discussion." <mod...@li...>
Date: Wednesday, 2 June 2021 at 19:25
To: "Environment Modules usage and discussion." <mod...@li...>
Subject: Re: [Modules] Using module-hide/forbid inside a modulefile

CAUTION: This email originated from outside of Palma Ceia SemiDesign. Links or attachments may be unsafe.

Le mer. 2 juin 2021 à 14:50, Mark Waterhouse <mar...@pc...<mailto:mar...@pc...>> a écrit :
Hi list

I have a common set of applications which are loaded as part of a default environment setup.
Today, most of our machines are using a RedHat/CentOS base and the modulefiles we have all work fine.

We have a standard set of tools which are loaded into the environment and some of these require modification to LD_LIBRARY_PATH.

I recently deployed a new Debian based OS and found that our standard tool installations ‘break’ modules.
LD_LIBRARY_PATH is changed and tcl on Debian doesn’t like this.
I started to look for a solution to this but then realized that the tool in question was not supported on Debian so even had I resolved the LD_LIBRARY_PATH issue, I would be no closer.


I was reading through the cookbook (https://modules.readthedocs.io/en/latest/cookbook.html) to see if there were some good examples and realized I could do this by testing for the existence of a file (/usr/lib/os-release) and, if this didn’t exist, I could ignore the rest of the code.

I then came across module-hide and decided that this would be a better idea.
I could load a ‘common’ module which, based on the OS, I could forbid access to these tools on operating systems where the tool was not supported.
It looks like module-hide / module-forbid are only available in .modulerc and this led to my posting.


Is it possible to do something like this (module-forbid is the bit that I’m stumped on)
#%Module 1.0
#

# Some OS configurations are not supported for some tools
#  Debian
# For these hosts, we will hide all of the tools from Vendor X
setenv DEBHOST /usr/lib/os-release

set cmd { open [getenv DEBHOST] r }
if { ! [catch $cmd errmsg] } {
  module-forbid vendor/X/*
  module-hide vendor/X/*
}

I tried this and I get no error but the vendor modules still exist.
I wondered whether I could put some logic inside the .modulerc file but this would require changing all of my existing modulefiles; if I could work out the correct syntax for module-forbid/module-hide, I wouldn’t need to 😊


Does anyone have any suggestions?

Thanks in advance
Mark

Hi Mark,

You are close: to select all version of module vendor/X (let's says vendor/X/1.0, vendor/X/2.0), you just have to write:

module-forbid vendor/X
module-hide vendor/X

The extra * is taken literally by modules (which meant only the modulefile named vendor/X/* were set hidden and forbidden).

You could also simplify your OS-specific test condition:

if {[file stat /usr/lib/os-release]} {
    module-forbid vendor/X
    module-hide vendor/X
}

On a side note, if your LD_LIBRARY_PATH issue impacts the module command itself, you may look at the quarantine mechanism to protect module execution [1].

Regards,
Xavier

[1] https://modules.readthedocs.io/en/latest/MIGRATING.html#quarantine-mechanism-to-protect-module-execution

Re: [Modules] Using module-hide/forbid inside a modulefile

[Xavier D. <xav...@gm...>]

Hi Nick,

Le mer. 2 juin 2021 à 15:13, Nick Papior <nic...@gm...> a écrit :

> I agree, this would be nice.
>
> Had this on my todo to bring this to the board as well.
> On another note:
> - it would be nice if one could "module-unhide" in module files as well
>

module-hide is primarily made for site admins to enforce module hiding for
their users. Unhiding previously hidden modules is currently not in the
development roadmap, as it would break the setup made by the admins. I
would recommend to avoid hiding modules if some conditions are not met (or
to hide modules only if some conditions are met) rather trying to unhide
modules after hiding them.


> - it would be nice if one could change the defaults in module files as
> well so users don't accidentally unload something intended and reload
> something else.
>

Could you elaborate a bit more on this use case. I do not get it.

Regards,
Xavier

Re: [Modules] Using module-hide/forbid inside a modulefile

[<sys...@xn...>]

Hello together,
well, what kind of problem did you have with LD_LIBRARY_PATH on Debian?
And what Version did you are using?

I use 9, 10 and 11 and I had no problems with "Module", but I compile it on each Node freshly....
Best regards from Berlin

Matthias

-------------------------------------------------------------------------
The diversity of human dignity
"Jede Handlung, die mit gutem Willen und Wirksamkeit
ausgeführt wird, ist eine mystische Handlung"

> On Mittwoch, Juni 02, 2021 at 3:13 PM, Nick Papior <nic...@gm... (mailto:nic...@gm...)> wrote:
> I agree, this would be nice.
>
> Had this on my todo to bring this to the board as well.
> On another note:
> - it would be nice if one could "module-unhide" in module files as well
> - it would be nice if one could change the defaults in module files as well so users don't accidentally unload something intended and reload something else.
>
>
> Den ons. 2. jun. 2021 kl. 14.50 skrev Mark Waterhouse <mar...@pc... (mailto:mar...@pc...)>:
> >
> > Hi list
> >
> >
> >
> >
> >
> > I have a common set of applications which are loaded as part of a default environment setup.
> >
> >
> > Today, most of our machines are using a RedHat/CentOS base and the modulefiles we have all work fine.
> >
> >
> >
> >
> >
> > We have a standard set of tools which are loaded into the environment and some of these require modification to LD_LIBRARY_PATH.
> >
> >
> >
> >
> >
> > I recently deployed a new Debian based OS and found that our standard tool installations ‘break’ modules.
> >
> >
> > LD_LIBRARY_PATH is changed and tcl on Debian doesn’t like this.
> >
> >
> > I started to look for a solution to this but then realized that the tool in question was not supported on Debian so even had I resolved the LD_LIBRARY_PATH issue, I would be no closer.
> >
> >
> >
> >
> >
> >
> >
> >
> > I was reading through the cookbook (https://modules.readthedocs.io/en/latest/cookbook.html) to see if there were some good examples and realized I could do this by testing for the existence of a file (/usr/lib/os-release) and, if this didn’t exist, I could ignore the rest of the code.
> >
> >
> >
> >
> >
> > I then came across module-hide and decided that this would be a better idea.
> >
> >
> > I could load a ‘common’ module which, based on the OS, I could forbid access to these tools on operating systems where the tool was not supported.
> >
> >
> > It looks like module-hide / module-forbid are only available in .modulerc and this led to my posting.
> >
> >
> >
> >
> >
> >
> >
> >
> > Is it possible to do something like this (module-forbid is the bit that I’m stumped on)
> >
> >
> > #%Module 1.0
> >
> >
> > #
> >
> >
> >
> >
> >
> > # Some OS configurations are not supported for some tools
> >
> >
> > # Debian
> >
> >
> > # For these hosts, we will hide all of the tools from Vendor X
> >
> >
> > setenv DEBHOST /usr/lib/os-release
> >
> >
> >
> >
> >
> > set cmd { open [getenv DEBHOST] r }
> >
> >
> > if { ! [catch $cmd errmsg] } {
> >
> >
> > module-forbid vendor/X/*
> >
> >
> > module-hide vendor/X/*
> >
> >
> > }
> >
> >
> >
> >
> >
> > I tried this and I get no error but the vendor modules still exist.
> >
> >
> > I wondered whether I could put some logic inside the .modulerc file but this would require changing all of my existing modulefiles; if I could work out the correct syntax for module-forbid/module-hide, I wouldn’t need to 😊
> >
> >
> >
> >
> >
> >
> >
> >
> > Does anyone have any suggestions?
> >
> >
> >
> >
> >
> > Thanks in advance
> >
> >
> > Mark
> >
> >
> >
> > _______________________________________________
> > Modules-interest mailing list
> > Mod...@li... (mailto:Mod...@li...)
> > https://lists.sourceforge.net/lists/listinfo/modules-interest
>
>
> --
> Kind regards Nick _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest

Re: [Modules] Using module-hide/forbid inside a modulefile

[Xavier D. <xav...@gm...>]

Le mer. 2 juin 2021 à 14:50, Mark Waterhouse <mar...@pc...> a
écrit :

> Hi list
>
>
>
> I have a common set of applications which are loaded as part of a default
> environment setup.
>
> Today, most of our machines are using a RedHat/CentOS base and the
> modulefiles we have all work fine.
>
>
>
> We have a standard set of tools which are loaded into the environment and
> some of these require modification to LD_LIBRARY_PATH.
>
>
>
> I recently deployed a new Debian based OS and found that our standard tool
> installations ‘break’ modules.
>
> LD_LIBRARY_PATH is changed and tcl on Debian doesn’t like this.
>
> I started to look for a solution to this but then realized that the tool
> in question was not supported on Debian so even had I resolved the
> LD_LIBRARY_PATH issue, I would be no closer.
>
>
>
>
>
> I was reading through the cookbook (
> https://modules.readthedocs.io/en/latest/cookbook.html) to see if there
> were some good examples and realized I could do this by testing for the
> existence of a file (/usr/lib/os-release) and, if this didn’t exist, I
> could ignore the rest of the code.
>
>
>
> I then came across module-hide and decided that this would be a better
> idea.
>
> I could load a ‘common’ module which, based on the OS, I could forbid
> access to these tools on operating systems where the tool was not supported.
>
> It looks like module-hide / module-forbid are only available in .modulerc
> and this led to my posting.
>
>
>
>
>
> Is it possible to do something like this (module-forbid is the bit that
> I’m stumped on)
>
> #%Module 1.0
>
> #
>
>
>
> # Some OS configurations are not supported for some tools
>
> #  Debian
>
> # For these hosts, we will hide all of the tools from Vendor X
>
> setenv DEBHOST /usr/lib/os-release
>
>
>
> set cmd { open [getenv DEBHOST] r }
>
> if { ! [catch $cmd errmsg] } {
>
>   module-forbid vendor/X/*
>
>   module-hide vendor/X/*
>
> }
>
>
>
> I tried this and I get no error but the vendor modules still exist.
>
> I wondered whether I could put some logic inside the .modulerc file but
> this would require changing all of my existing modulefiles; if I could work
> out the correct syntax for module-forbid/module-hide, I wouldn’t need to
> 😊
>
>
>
>
>
> Does anyone have any suggestions?
>
>
>
> Thanks in advance
>
> Mark
>

Hi Mark,

You are close: to select all version of module vendor/X (let's says
vendor/X/1.0, vendor/X/2.0), you just have to write:

module-forbid vendor/X

module-hide vendor/X


The extra * is taken literally by modules (which meant only the modulefile
named vendor/X/* were set hidden and forbidden).

You could also simplify your OS-specific test condition:

if {[file stat /usr/lib/os-release]} {
    module-forbid vendor/X
    module-hide vendor/X
}

On a side note, if your LD_LIBRARY_PATH issue impacts the module command
itself, you may look at the quarantine mechanism to protect module
execution [1].

Regards,
Xavier

[1]
https://modules.readthedocs.io/en/latest/MIGRATING.html#quarantine-mechanism-to-protect-module-execution

Re: [Modules] Using module-hide/forbid inside a modulefile

[Nick P. <nic...@gm...>]

I agree, this would be nice.

Had this on my todo to bring this to the board as well.
On another note:
- it would be nice if one could "module-unhide" in module files as well
- it would be nice if one could change the defaults in module files as well
so users don't accidentally unload something intended and reload something
else.

Den ons. 2. jun. 2021 kl. 14.50 skrev Mark Waterhouse <
mar...@pc...>:

> Hi list
>
>
>
> I have a common set of applications which are loaded as part of a default
> environment setup.
>
> Today, most of our machines are using a RedHat/CentOS base and the
> modulefiles we have all work fine.
>
>
>
> We have a standard set of tools which are loaded into the environment and
> some of these require modification to LD_LIBRARY_PATH.
>
>
>
> I recently deployed a new Debian based OS and found that our standard tool
> installations ‘break’ modules.
>
> LD_LIBRARY_PATH is changed and tcl on Debian doesn’t like this.
>
> I started to look for a solution to this but then realized that the tool
> in question was not supported on Debian so even had I resolved the
> LD_LIBRARY_PATH issue, I would be no closer.
>
>
>
>
>
> I was reading through the cookbook (
> https://modules.readthedocs.io/en/latest/cookbook.html) to see if there
> were some good examples and realized I could do this by testing for the
> existence of a file (/usr/lib/os-release) and, if this didn’t exist, I
> could ignore the rest of the code.
>
>
>
> I then came across module-hide and decided that this would be a better
> idea.
>
> I could load a ‘common’ module which, based on the OS, I could forbid
> access to these tools on operating systems where the tool was not supported.
>
> It looks like module-hide / module-forbid are only available in .modulerc
> and this led to my posting.
>
>
>
>
>
> Is it possible to do something like this (module-forbid is the bit that
> I’m stumped on)
>
> #%Module 1.0
>
> #
>
>
>
> # Some OS configurations are not supported for some tools
>
> #  Debian
>
> # For these hosts, we will hide all of the tools from Vendor X
>
> setenv DEBHOST /usr/lib/os-release
>
>
>
> set cmd { open [getenv DEBHOST] r }
>
> if { ! [catch $cmd errmsg] } {
>
>   module-forbid vendor/X/*
>
>   module-hide vendor/X/*
>
> }
>
>
>
> I tried this and I get no error but the vendor modules still exist.
>
> I wondered whether I could put some logic inside the .modulerc file but
> this would require changing all of my existing modulefiles; if I could work
> out the correct syntax for module-forbid/module-hide, I wouldn’t need to
> 😊
>
>
>
>
>
> Does anyone have any suggestions?
>
>
>
> Thanks in advance
>
> Mark
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest
>


-- 
Kind regards Nick

[Modules] Using module-hide/forbid inside a modulefile

[Mark W. <mar...@pc...>]

Hi list

I have a common set of applications which are loaded as part of a default environment setup.
Today, most of our machines are using a RedHat/CentOS base and the modulefiles we have all work fine.

We have a standard set of tools which are loaded into the environment and some of these require modification to LD_LIBRARY_PATH.

I recently deployed a new Debian based OS and found that our standard tool installations ‘break’ modules.
LD_LIBRARY_PATH is changed and tcl on Debian doesn’t like this.
I started to look for a solution to this but then realized that the tool in question was not supported on Debian so even had I resolved the LD_LIBRARY_PATH issue, I would be no closer.


I was reading through the cookbook (https://modules.readthedocs.io/en/latest/cookbook.html) to see if there were some good examples and realized I could do this by testing for the existence of a file (/usr/lib/os-release) and, if this didn’t exist, I could ignore the rest of the code.

I then came across module-hide and decided that this would be a better idea.
I could load a ‘common’ module which, based on the OS, I could forbid access to these tools on operating systems where the tool was not supported.
It looks like module-hide / module-forbid are only available in .modulerc and this led to my posting.


Is it possible to do something like this (module-forbid is the bit that I’m stumped on)
#%Module 1.0
#

# Some OS configurations are not supported for some tools
#  Debian
# For these hosts, we will hide all of the tools from Vendor X
setenv DEBHOST /usr/lib/os-release

set cmd { open [getenv DEBHOST] r }
if { ! [catch $cmd errmsg] } {
  module-forbid vendor/X/*
  module-hide vendor/X/*
}

I tried this and I get no error but the vendor modules still exist.
I wondered whether I could put some logic inside the .modulerc file but this would require changing all of my existing modulefiles; if I could work out the correct syntax for module-forbid/module-hide, I wouldn’t need to 😊


Does anyone have any suggestions?

Thanks in advance
Mark