modules-interest Mailing List for Environment Modules

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Dear All,

Modules now has its dedicated domain name: envmodules.io

Website is now reachable via https://envmodules.io

Best regards,
Xavier

Bonjour Laurent,

Laurent BESSON <lau...@ea...> writes:

> Hello Roger,
>
> I would say this is the right behaviour. If you want Modules to unset your variables when unloading the module, you should not use:
>
> if { [ module-info mode load] } {
> ....
>
> I would simply rewrite your module like this:

That was it.

Merci beaucoup!
Roger

Hello Roger,

I would say this is the right behaviour. If you want Modules to unset your variables when unloading the module, you should not use:

if { [ module-info mode load] } {
....

I would simply rewrite your module like this:

#%Module1.0#####################################################################
##
## GCC modulefile
##
proc ModulesHelp { } {
        global version

        puts stderr "\tSets up environment for GCC v$version."
}

module-whatis   "sets up environment for GCC v13.3.0"

# for Tcl script use only
set     version 13.3.0
set     root    /usr/local

conflict gcc

prepend-path	INFOPATH	$root/share/info
setenv      	LD_LIBRARY_PATH	$root/gcc13
prepend-path	MANPATH		$root/share/man
prepend-path	PATH		$root/bin/
setenv                GCC                 $root/bin/gcc13

if { [ module-info mode load] } {
    file link -symbolic /home/rmason/bin/gcc $root/bin/gcc13
    file link -symbolic /home/rmason/bin/g++ $root/bin/g++13;
    file link -symbolic /home/rmason/bin/gfortran $root/bin/gfortran13; }

if { [ module-info mode ] == "unload" || [ module-info mode ] == "remove" } {
    exec rm /home/rmason/bin/gcc;      # 
    exec rm /home/rmason/bin/g++;      # 
    exec rm /home/rmason/bin/gfortran; # }

Best regards,
Laurent

-----Message d'origine-----
De : Roger Mason via Modules-interest <mod...@li...> 
Envoyé : vendredi 17 octobre 2025 14:10
À : mod...@li...
Cc : Roger Mason <rm...@mu...>
Objet : [Modules] envars not unset when unloading

Hello,

When unloading this modulefile the envars it sets are not unset:

#%Module1.0#####################################################################
##
## GCC modulefile
##
proc ModulesHelp { } {
        global version

        puts stderr "\tSets up environment for GCC v$version."
}

module-whatis   "sets up environment for GCC v13.3.0"

# for Tcl script use only
set     version 13.3.0
set     root    /usr/local

conflict gcc

if { [ module-info mode load] } {
    prepend-path	INFOPATH	$root/share/info
    setenv      	LD_LIBRARY_PATH	$root/gcc13
    prepend-path	MANPATH		$root/share/man
    prepend-path	PATH		$root/bin/
    setenv          GCC                 $root/bin/gcc13
    file link -symbolic /home/rmason/bin/gcc $root/bin/gcc13
    file link -symbolic /home/rmason/bin/g++ $root/bin/g++13;
    file link -symbolic /home/rmason/bin/gfortran $root/bin/gfortran13; }

if { [ module-info mode ] == "unload" || [ module-info mode ] == "remove" } {
    exec rm /home/rmason/bin/gcc;      # 
    exec rm /home/rmason/bin/g++;      # 
    exec rm /home/rmason/bin/gfortran; # }

Session transcript:

rmason echo $LD_LIBRARY_PATH

rmason
rmason module load gcc/13.3.0
rmason echo $LD_LIBRARY_PATH
/usr/local/gcc13
module unload gcc/13.3.0 
rmason echo $LD_LIBRARY_PATH    
/usr/local/gcc13

I am running version modules-5.6.0 installed on FreeBSD-13.5 using the binary package system.

Thanks for nay help.
Roger

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

Hello,

When unloading this modulefile the envars it sets are not unset:

#%Module1.0#####################################################################
##
## GCC modulefile
##
proc ModulesHelp { } {
        global version

        puts stderr "\tSets up environment for GCC v$version."
}

module-whatis   "sets up environment for GCC v13.3.0"

# for Tcl script use only
set     version 13.3.0
set     root    /usr/local

conflict gcc

if { [ module-info mode load] } {
    prepend-path	INFOPATH	$root/share/info
    setenv      	LD_LIBRARY_PATH	$root/gcc13
    prepend-path	MANPATH		$root/share/man
    prepend-path	PATH		$root/bin/
    setenv          GCC                 $root/bin/gcc13
    file link -symbolic /home/rmason/bin/gcc $root/bin/gcc13
    file link -symbolic /home/rmason/bin/g++ $root/bin/g++13;
    file link -symbolic /home/rmason/bin/gfortran $root/bin/gfortran13;
}

if { [ module-info mode ] == "unload" || [ module-info mode ] == "remove" } {
    exec rm /home/rmason/bin/gcc;      # 
    exec rm /home/rmason/bin/g++;      # 
    exec rm /home/rmason/bin/gfortran; # 
}

Session transcript:

rmason echo $LD_LIBRARY_PATH

rmason
rmason module load gcc/13.3.0
rmason echo $LD_LIBRARY_PATH  
/usr/local/gcc13
module unload gcc/13.3.0 
rmason echo $LD_LIBRARY_PATH    
/usr/local/gcc13

I am running version modules-5.6.0 installed on FreeBSD-13.5 using the
binary package system.

Thanks for nay help.
Roger

Dear Xavier

Since our GitLab server will be shut down at the end of November, I have moved Pmodules to GitHub. The new URL is
https://github.com/Pmodules/Pmodules

Documentation is available at:
https://pmodules.github.io/

I wrote a short document summarising the required features we would need in Modules to replace Pmodules with Modules+site specific procedures/configuration:
https://github.com/Pmodules/Pmodules/wiki/Differences-between-Pmodules-and-Modules

Comments/suggestions how we can proceed are very welcome!

Best regards,

Achim

On 13 Sep 2025, at 15:16, Xavier Delaruelle <xav...@gm...> wrote:

Dear Achim,

Thanks for these informations. I am following the development of
Pmodules since several years through the PSI gitlab.

That's great if you would like to contribute here. Welcome :-)

Best regards,
Xavier

Le ven. 12 sept. 2025 à 11:39, Gsell, Achim <ach...@ps...> a écrit :

Dear Xavier,

thanks a lot for the answer and solution!

A little background on why I'm experimenting with this.

At the Paul Scherrer Institute (PSI), we use Pmodules. Pmodules is essentially a wrapper for Environment Modules 3.2.10 written in Bash. This wrapper implements additional features not available in the old implementation of the Environment Modules. Some of them are now available in the current version, or there is similar functionality available. I started developing Pmodules at a time when the development of the Environment Modules was not progressing. This changed and some of the features in Pmodules - like hierarchical modules - are now available in the Environment Modules. Other features like overlays, Lmod support, availability of modules depending on hostname and/or OS/version are not available.

Since developing and supporting a special version that is only used at PSI is lot of work, we are considering whether some of the Pmodule for PSI essential extensions could be incorporated into the Tcl Environment Modules. I would like to contribute to the project and have a significant part of my working time available for the implementation of these features.

Best regards

Achim

On 12 Sep 2025, at 07:39, Xavier Delaruelle <xav...@gm...> wrote:

Dear Achim,

First of all, I made a mistake in my analysis yesterday: defining
module-addpath procedure within the modulefile works just fine.

The issue you face comes from the Tcl evaluation context. When defined
in the siteconfig.tcl, the module-addpath procedure is evaluated in
the main execution context, not the one specific to modulefile
evaluation. Thus, modulefile commands like prepend-path called from
the main context are not the correct one adapted to the current
evaluation mode ("edit-path-sc" for scan mode or "prepend-path-un" for
unload mode).

To get the expected behavior, the prepend-path command should be run
from current modulefile evaluation context. It could be achieved by
changing the module-addpath procedure the following way:

proc module-addpath {path} {
  # get name of current module Tcl interp
  set itrp [getCurrentModfileInterpName]

  interp eval $itrp prepend-path MODULEPATH $path
}

I need to update the documentation to explain that along the
siteconfig.tcl modulefile_extra_cmds documentation.

Best regards,
Xavier

Le jeu. 11 sept. 2025 à 06:14, Xavier Delaruelle
<xav...@gm...> a écrit :

Dear Achim,

Thanks for your message. I can reproduce the issue you describe on my
side. Even when defining the module-addpath procedure within the
modulefile.

From a first quick analysis, it does not feel that this is the
indented behavior. I will need to investigate further down to find
what is going on.

Best regards,
Xavier

Le mer. 10 sept. 2025 à 10:57, Gsell, Achim <ach...@ps...> a écrit :

Dear All,

I'm currently playing with a hierarchical module structure, which is now supported in version 5.6. If I add a new directory to MODULEPATH in a modulefile itself, everything works fine. But as soon as I move the statement

prepend-path MODULEPATH $something

to a procedure inside my siteconfig.tcl file I run into two issues.

First: The path $something is not removed from MODULEPATH while unloading the module.

Second: module spider —indepth doesn’t show the modules in  $something.

Example:

I have the following (simplified) modulefile for gcc/15.2.0:

$ cat /afs/psi.ch/group/HPCE/Modules/Programming/modulefiles/gcc/15.2.0
#%Module

module-help "GCC compiler collection"
module-addpath {/afs/psi.ch/group/HPCE/Modules/Compiler/modulefiles/gcc/15.2.0}

In my siteconfig.tcl the procedure module-addpath is defined as:

proc module-addpath { path } {
    prepend-path MODULEPATH $path
}

I have the following modulefiles:

[gsell@merlin-c-002 ~]$ find /afs/psi.ch/group/HPCE/Modules/*/modulefiles -type f
/afs/psi.ch/group/HPCE/Modules/Compiler/modulefiles/gcc/15.2.0/OpenBLAS/0.3.30
/afs/psi.ch/group/HPCE/Modules/Programming/modulefiles/gcc/15.2.0

and MODULEPATH is set to:

[gsell@merlin-c-002 ~]$ echo $MODULEPATH
/afs/psi.ch/group/HPCE/Modules/Programming/modulefiles

The spider command should show the OpenBLAS module, but it doesn’t:

[gsell@merlin-c-002 ~]$ module spider --indepth
------------ /afs/psi.ch/group/HPCE/Modules/Programming/modulefiles -------------
gcc/15.2.0

Key:
modulepath

After loading the gcc module, the OpenBLAS module is available, this is correct:

[gsell@merlin-c-002 ~]$ module load gcc/15.2.0
[gsell@merlin-c-002 ~]$ module avail
-------- /afs/psi.ch/group/HPCE/Modules/Compiler/modulefiles/gcc/15.2.0 ---------
OpenBLAS/0.3.30

------------ /afs/psi.ch/group/HPCE/Modules/Programming/modulefiles -------------
gcc/15.2.0
Key:
loaded  modulepath
But after unloading the gcc module, the OpenBLAS module is still available:

[gsell@merlin-c-002 ~]$ module unload gcc/15.2.0
[gsell@merlin-c-002 ~]$ module avail
-------- /afs/psi.ch/group/HPCE/Modules/Compiler/modulefiles/gcc/15.2.0 ---------
OpenBLAS/0.3.30

------------ /afs/psi.ch/group/HPCE/Modules/Programming/modulefiles -------------
gcc/15.2.0

Key:
modulepath
and the added directory is still in MODULEPATH:

[gsell@merlin-c-002 ~]$ echo $MODULEPATH
/afs/psi.ch/group/HPCE/Modules/Compiler/modulefiles/gcc/15.2.0:/afs/psi.ch/group/HPCE/Modules/Programming/modulefiles

If I replace in the gcc/15.2.0 modulefile

module-addpath {/afs/psi.ch/group/HPCE/Modules/Compiler/modulefiles/gcc/15.2.0}

with

prepend-path MODULEPATH {/afs/psi.ch/group/HPCE/Modules/Compiler/modulefiles/gcc/15.2.0}

everything works as expected.

I’m not sure whether this behaviour is intended or a bug. If it is intended, how can I add something to MODULEPATH in a procedure?

Best regards,

Achim

_______________________________________________
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

Hi Marc,

Many thanks for your message.

I have added a feature request to add a new configure option to define
if paginate should be done or not, without changing the pager
definition.

I have also added another feature request to add an abbreviated
version for --paginate option. Maybe -p should be ok, as it seems to
be the standard abbreviation used by commands (like git).

I do not see any command having a abbreviation for --no-pager. So I
would prefer not to have an abbreviation for this one.

Best regards,
Xavier

Le jeu. 9 oct. 2025 à 19:07, Paul Markfort <pau...@gm...> a écrit :
>
> For now, you could define an alias of, module-no-pager which is just "module --no-pager" (autocomplete would fill it out if you use module-n<TAB>).
>
> If you set MODULES_PAGER="" (or use --no-pager).
> Then you can still pipe the output of things like "module avail" through more, etc (which is what I would expect most users to do if it didn't page by default - in the old days that was not easy as the output of module avail went to stderr).
>
> If you currently use:  "module avail | cat"  this will also stop paging (any redirection of stdout will turn off paging).
>
>
> I do think it could be helpful to add the ability to change the default to --no-pager, then have a --pager  option to reverse it.
> Maybe even a --pager=   (so you can override the default without setting a variable)
> That is just --pager  Means use default
> or you could use --pager=more
>
>
>
> I think pager and paginate do different things (I am not sure what, probably needs more detail in the man page).
>
>         --no-pager
>                Do not pipe message output into a pager.
>
>         --paginate
>                Pipe  all  message  output  into  less  (or  if  set,  to  the  command  referred  in
>                MODULES_PAGER  variable) if error output stream is a terminal. See also MODULES_PAGER
>                section.
>
>         --redirect
>                Send message output to stdout instead of stderr. Only supported on sh, bash, ksh, zsh
>                and fish shells.
>                 (I think this is the default for information commands like module avail).
>
>         --no-redirect
>                Do not send message output to stdout. Keep it on stderr.
>
>
>
>
>
>
>
>
>
>
>
> On 2025-10-09 4:36 AM, Marc Castells wrote:
> > Hi Xavier, All,
> >
> > Is there a way for a user to configure the default pager mode in Modules? As far as I can see, the options are:
> >    a) Disable the pager feature altogether by clearing MODULES_PAGER or assigning it the value "cat". No pagination is available.
> >    b) Accept the default pagination with "less -eFKRX" and make the user disable it manually with "-no-pager"
> >
> > I am looking for a third option:
> >    c) Keep "less -eFKRX"  in MODULES_PAGER but allow the default pagination to be no-pager. If the user wanted to paginate the output, they would need to explicitly use "-paginate"
> >
> > This c) option to me is the most natural behaviour and allows the user to configure a default pagination mode whilst having the option to override it with an explicit command line switch. The current functionality is not neutral as It's skewed towards displaying the output with pagination by default.
> >
> > While on the subject, would it be possible to consider shortcuts for the "-paginate" and "-no-pager" command line options?
> >
> > Many thanks,
> >
> > Marc.
> >
> >
> > _______________________________________________
> > Modules-interest mailing list
> > Mod...@li...
> > https://lists.sourceforge.net/lists/listinfo/modules-interest
> >
>
> --
> --------------------------------------------------------
> 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/
> --------------------------------------------------------
>
>
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest

For now, you could define an alias of, module-no-pager which is just "module --no-pager" (autocomplete would fill it out if you use module-n<TAB>).

If you set MODULES_PAGER="" (or use --no-pager).
Then you can still pipe the output of things like "module avail" through more, etc (which is what I would expect most users to do if it didn't page by default - in the old days that was not easy as the output of module avail went to stderr).

If you currently use:  "module avail | cat"  this will also stop paging (any redirection of stdout will turn off paging).

I do think it could be helpful to add the ability to change the default to --no-pager, then have a --pager  option to reverse it.
Maybe even a --pager=   (so you can override the default without setting a variable)
That is just --pager  Means use default
or you could use --pager=more

I think pager and paginate do different things (I am not sure what, probably needs more detail in the man page).

        --no-pager
               Do not pipe message output into a pager.

        --paginate
               Pipe  all  message  output  into  less  (or  if  set,  to  the  command  referred  in
               MODULES_PAGER  variable) if error output stream is a terminal. See also MODULES_PAGER
               section.

        --redirect
               Send message output to stdout instead of stderr. Only supported on sh, bash, ksh, zsh
               and fish shells.
		(I think this is the default for information commands like module avail).

        --no-redirect
               Do not send message output to stdout. Keep it on stderr.

On 2025-10-09 4:36 AM, Marc Castells wrote:
> Hi Xavier, All,
> 
> Is there a way for a user to configure the default pager mode in Modules? As far as I can see, the options are:
>    a) Disable the pager feature altogether by clearing MODULES_PAGER or assigning it the value "cat". No pagination is available.
>    b) Accept the default pagination with "less -eFKRX" and make the user disable it manually with "-no-pager"
> 
> I am looking for a third option:
>    c) Keep "less -eFKRX"  in MODULES_PAGER but allow the default pagination to be no-pager. If the user wanted to paginate the output, they would need to explicitly use "-paginate"
> 
> This c) option to me is the most natural behaviour and allows the user to configure a default pagination mode whilst having the option to override it with an explicit command line switch. The current functionality is not neutral as It's skewed towards displaying the output with pagination by default.
> 
> While on the subject, would it be possible to consider shortcuts for the "-paginate" and "-no-pager" command line options?
> 
> Many thanks,
> 
> Marc.
> 
> 
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest
> 

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

Hi Xavier, All,

Is there a way for a user to configure the default pager mode in Modules? As far as I can see, the options are:
  a) Disable the pager feature altogether by clearing MODULES_PAGER or assigning it the value "cat". No pagination is available.
  b) Accept the default pagination with "less -eFKRX" and make the user disable it manually with "-no-pager"

I am looking for a third option:
  c) Keep "less -eFKRX"  in MODULES_PAGER but allow the default pagination to be no-pager. If the user wanted to paginate the output, they would need to explicitly use "-paginate"

This c) option to me is the most natural behaviour and allows the user to configure a default pagination mode whilst having the option to override it with an explicit command line switch. The current functionality is not neutral as It's skewed towards displaying the output with pagination by default.

While on the subject, would it be possible to consider shortcuts for the "-paginate" and "-no-pager" command line options?

Many thanks,

Marc.

I have changed the dark theme to use the red logo. It is true that it
fits well both theme. Unfortunately, there is the possibility to only
have 2 themes (one light and one dark).

Regards,
Xavier

Le lun. 6 oct. 2025 à 18:53, Paul Markfort <pau...@gm...> a écrit :
>
> The https://modules.readthedocs.io/en/latest/_static/modules_red.svg actually stands out very well in dark mode (rather than the modules_white.svg).
> I found this out by overriding the text and background while in light mode (black background, reddish text to match the image).
>
>
>
> And, I know this is picky ( maybe you could start a color trend ;) ):
> Is there a way (in dark mode) to set the red of modules_red.svg,
> or maybe Amber as the text color (other than changing my browser settings)?
> Perhaps, an additional dark mode (or two)?
>
>
> I find that amber (or colors similar to it like the red of modules_red.svg) on black is easier to read than white on black (particularly in low light situations - remember the days of amber monitors?).
> I set terminals (and the windows cmd.exe window) to yellow-amber text on a black background:
> XTerm*background:               black
> XTerm*foreground:               rgb:dc/84/00
>
>
>
>
>
> On 2025-10-06 12:42 AM, Xavier Delaruelle wrote:
> > Hello All,
> >
> > I have updated the documentation website to use the "Furo" sphinx theme.
> >
> > I feel like it globally improves the readability. Current page table
> > of content is available on the right side. It is also possible to
> > switch between light and dark mode.
> >
> > Please tell me if you spot something awkward.
> >
> > https://modules.readthedocs.io/en/latest/
> >
> > Best regards,
> > Xavier
> >
> >
> > _______________________________________________
> > Modules-interest mailing list
> > Mod...@li...
> > https://lists.sourceforge.net/lists/listinfo/modules-interest
> >
>
> --
> --------------------------------------------------------
> 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/
> --------------------------------------------------------
>
>
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest

The https://modules.readthedocs.io/en/latest/_static/modules_red.svg actually stands out very well in dark mode (rather than the modules_white.svg).
I found this out by overriding the text and background while in light mode (black background, reddish text to match the image).

And, I know this is picky ( maybe you could start a color trend ;) ):
Is there a way (in dark mode) to set the red of modules_red.svg,
or maybe Amber as the text color (other than changing my browser settings)?
Perhaps, an additional dark mode (or two)?

I find that amber (or colors similar to it like the red of modules_red.svg) on black is easier to read than white on black (particularly in low light situations - remember the days of amber monitors?).
I set terminals (and the windows cmd.exe window) to yellow-amber text on a black background:
XTerm*background:               black
XTerm*foreground:               rgb:dc/84/00

On 2025-10-06 12:42 AM, Xavier Delaruelle wrote:
> Hello All,
> 
> I have updated the documentation website to use the "Furo" sphinx theme.
> 
> I feel like it globally improves the readability. Current page table
> of content is available on the right side. It is also possible to
> switch between light and dark mode.
> 
> Please tell me if you spot something awkward.
> 
> https://modules.readthedocs.io/en/latest/
> 
> Best regards,
> Xavier
> 
> 
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest
> 

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

Hello All,

I have updated the documentation website to use the "Furo" sphinx theme.

I feel like it globally improves the readability. Current page table
of content is available on the right side. It is also possible to
switch between light and dark mode.

Please tell me if you spot something awkward.

https://modules.readthedocs.io/en/latest/

Best regards,
Xavier

Dear Xavier

> On 13 Sep 2025, at 15:16, Xavier Delaruelle <xav...@gm...> wrote:
> 
> Dear Achim,
> 
> Thanks for these informations. I am following the development of
> Pmodules since several years through the PSI gitlab.
> 
> That's great if you would like to contribute here. Welcome :-)

:-) 

In the next few days, I will write a document summarizing the differences between Pmodules and Tcl Environment Modules. There are some “low hanging fruit” I can start with. Some PSI-specific extensions must certainly be implemented in a siteconfig.tcl file. I did this already for our hierarchical module structure. Overlays and Lmod integration are certainly the biggest tasks.

Best regards 

Achim

> 
> Best regards,
> Xavier
> 
> Le ven. 12 sept. 2025 à 11:39, Gsell, Achim <ach...@ps...> a écrit :
>> 
>> Dear Xavier,
>> 
>> thanks a lot for the answer and solution!
>> 
>> A little background on why I'm experimenting with this.
>> 
>> At the Paul Scherrer Institute (PSI), we use Pmodules. Pmodules is essentially a wrapper for Environment Modules 3.2.10 written in Bash. This wrapper implements additional features not available in the old implementation of the Environment Modules. Some of them are now available in the current version, or there is similar functionality available. I started developing Pmodules at a time when the development of the Environment Modules was not progressing. This changed and some of the features in Pmodules - like hierarchical modules - are now available in the Environment Modules. Other features like overlays, Lmod support, availability of modules depending on hostname and/or OS/version are not available.
>> 
>> Since developing and supporting a special version that is only used at PSI is lot of work, we are considering whether some of the Pmodule for PSI essential extensions could be incorporated into the Tcl Environment Modules. I would like to contribute to the project and have a significant part of my working time available for the implementation of these features.
>> 
>> Best regards
>> 
>> Achim
>> 
>> 
>> 
>>> On 12 Sep 2025, at 07:39, Xavier Delaruelle <xav...@gm...> wrote:
>>> 
>>> Dear Achim,
>>> 
>>> First of all, I made a mistake in my analysis yesterday: defining
>>> module-addpath procedure within the modulefile works just fine.
>>> 
>>> The issue you face comes from the Tcl evaluation context. When defined
>>> in the siteconfig.tcl, the module-addpath procedure is evaluated in
>>> the main execution context, not the one specific to modulefile
>>> evaluation. Thus, modulefile commands like prepend-path called from
>>> the main context are not the correct one adapted to the current
>>> evaluation mode ("edit-path-sc" for scan mode or "prepend-path-un" for
>>> unload mode).
>>> 
>>> To get the expected behavior, the prepend-path command should be run
>>> from current modulefile evaluation context. It could be achieved by
>>> changing the module-addpath procedure the following way:
>>> 
>>> proc module-addpath {path} {
>>>   # get name of current module Tcl interp
>>>   set itrp [getCurrentModfileInterpName]
>>> 
>>>   interp eval $itrp prepend-path MODULEPATH $path
>>> }
>>> 
>>> I need to update the documentation to explain that along the
>>> siteconfig.tcl modulefile_extra_cmds documentation.
>>> 
>>> Best regards,
>>> Xavier
>>> 
>>> Le jeu. 11 sept. 2025 à 06:14, Xavier Delaruelle
>>> <xav...@gm...> a écrit :
>>>> 
>>>> Dear Achim,
>>>> 
>>>> Thanks for your message. I can reproduce the issue you describe on my
>>>> side. Even when defining the module-addpath procedure within the
>>>> modulefile.
>>>> 
>>>> From a first quick analysis, it does not feel that this is the
>>>> indented behavior. I will need to investigate further down to find
>>>> what is going on.
>>>> 
>>>> Best regards,
>>>> Xavier
>>>> 
>>>> Le mer. 10 sept. 2025 à 10:57, Gsell, Achim <ach...@ps...> a écrit :
>>>>> 
>>>>> Dear All,
>>>>> 
>>>>> I'm currently playing with a hierarchical module structure, which is now supported in version 5.6. If I add a new directory to MODULEPATH in a modulefile itself, everything works fine. But as soon as I move the statement
>>>>> 
>>>>> prepend-path MODULEPATH $something
>>>>> 
>>>>> to a procedure inside my siteconfig.tcl file I run into two issues.
>>>>> 
>>>>> First: The path $something is not removed from MODULEPATH while unloading the module.
>>>>> 
>>>>> Second: module spider —indepth doesn’t show the modules in  $something.
>>>>> 
>>>>> Example:
>>>>> 
>>>>> I have the following (simplified) modulefile for gcc/15.2.0:
>>>>> 
>>>>> $ cat /afs/psi.ch/group/HPCE/Modules/Programming/modulefiles/gcc/15.2.0
>>>>> #%Module
>>>>> 
>>>>> module-help "GCC compiler collection"
>>>>> module-addpath {/afs/psi.ch/group/HPCE/Modules/Compiler/modulefiles/gcc/15.2.0}
>>>>> 
>>>>> In my siteconfig.tcl the procedure module-addpath is defined as:
>>>>> 
>>>>> proc module-addpath { path } {
>>>>>     prepend-path MODULEPATH $path
>>>>> }
>>>>> 
>>>>> I have the following modulefiles:
>>>>> 
>>>>> [gsell@merlin-c-002 ~]$ find /afs/psi.ch/group/HPCE/Modules/*/modulefiles -type f
>>>>> /afs/psi.ch/group/HPCE/Modules/Compiler/modulefiles/gcc/15.2.0/OpenBLAS/0.3.30
>>>>> /afs/psi.ch/group/HPCE/Modules/Programming/modulefiles/gcc/15.2.0
>>>>> 
>>>>> and MODULEPATH is set to:
>>>>> 
>>>>> [gsell@merlin-c-002 ~]$ echo $MODULEPATH
>>>>> /afs/psi.ch/group/HPCE/Modules/Programming/modulefiles
>>>>> 
>>>>> The spider command should show the OpenBLAS module, but it doesn’t:
>>>>> 
>>>>> [gsell@merlin-c-002 ~]$ module spider --indepth
>>>>> ------------ /afs/psi.ch/group/HPCE/Modules/Programming/modulefiles -------------
>>>>> gcc/15.2.0
>>>>> 
>>>>> Key:
>>>>> modulepath
>>>>> 
>>>>> After loading the gcc module, the OpenBLAS module is available, this is correct:
>>>>> 
>>>>> [gsell@merlin-c-002 ~]$ module load gcc/15.2.0
>>>>> [gsell@merlin-c-002 ~]$ module avail
>>>>> -------- /afs/psi.ch/group/HPCE/Modules/Compiler/modulefiles/gcc/15.2.0 ---------
>>>>> OpenBLAS/0.3.30
>>>>> 
>>>>> ------------ /afs/psi.ch/group/HPCE/Modules/Programming/modulefiles -------------
>>>>> gcc/15.2.0
>>>>> Key:
>>>>> loaded  modulepath
>>>>> But after unloading the gcc module, the OpenBLAS module is still available:
>>>>> 
>>>>> [gsell@merlin-c-002 ~]$ module unload gcc/15.2.0
>>>>> [gsell@merlin-c-002 ~]$ module avail
>>>>> -------- /afs/psi.ch/group/HPCE/Modules/Compiler/modulefiles/gcc/15.2.0 ---------
>>>>> OpenBLAS/0.3.30
>>>>> 
>>>>> ------------ /afs/psi.ch/group/HPCE/Modules/Programming/modulefiles -------------
>>>>> gcc/15.2.0
>>>>> 
>>>>> Key:
>>>>> modulepath
>>>>> and the added directory is still in MODULEPATH:
>>>>> 
>>>>> [gsell@merlin-c-002 ~]$ echo $MODULEPATH
>>>>> /afs/psi.ch/group/HPCE/Modules/Compiler/modulefiles/gcc/15.2.0:/afs/psi.ch/group/HPCE/Modules/Programming/modulefiles
>>>>> 
>>>>> 
>>>>> If I replace in the gcc/15.2.0 modulefile
>>>>> 
>>>>> module-addpath {/afs/psi.ch/group/HPCE/Modules/Compiler/modulefiles/gcc/15.2.0}
>>>>> 
>>>>> with
>>>>> 
>>>>> prepend-path MODULEPATH {/afs/psi.ch/group/HPCE/Modules/Compiler/modulefiles/gcc/15.2.0}
>>>>> 
>>>>> everything works as expected.
>>>>> 
>>>>> I’m not sure whether this behaviour is intended or a bug. If it is intended, how can I add something to MODULEPATH in a procedure?
>>>>> 
>>>>> Best regards,
>>>>> 
>>>>> Achim
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> 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

Dear Achim,

Thanks for these informations. I am following the development of
Pmodules since several years through the PSI gitlab.

That's great if you would like to contribute here. Welcome :-)

Best regards,
Xavier

Le ven. 12 sept. 2025 à 11:39, Gsell, Achim <ach...@ps...> a écrit :
>
> Dear Xavier,
>
> thanks a lot for the answer and solution!
>
> A little background on why I'm experimenting with this.
>
> At the Paul Scherrer Institute (PSI), we use Pmodules. Pmodules is essentially a wrapper for Environment Modules 3.2.10 written in Bash. This wrapper implements additional features not available in the old implementation of the Environment Modules. Some of them are now available in the current version, or there is similar functionality available. I started developing Pmodules at a time when the development of the Environment Modules was not progressing. This changed and some of the features in Pmodules - like hierarchical modules - are now available in the Environment Modules. Other features like overlays, Lmod support, availability of modules depending on hostname and/or OS/version are not available.
>
> Since developing and supporting a special version that is only used at PSI is lot of work, we are considering whether some of the Pmodule for PSI essential extensions could be incorporated into the Tcl Environment Modules. I would like to contribute to the project and have a significant part of my working time available for the implementation of these features.
>
> Best regards
>
> Achim
>
>
>
> > On 12 Sep 2025, at 07:39, Xavier Delaruelle <xav...@gm...> wrote:
> >
> > Dear Achim,
> >
> > First of all, I made a mistake in my analysis yesterday: defining
> > module-addpath procedure within the modulefile works just fine.
> >
> > The issue you face comes from the Tcl evaluation context. When defined
> > in the siteconfig.tcl, the module-addpath procedure is evaluated in
> > the main execution context, not the one specific to modulefile
> > evaluation. Thus, modulefile commands like prepend-path called from
> > the main context are not the correct one adapted to the current
> > evaluation mode ("edit-path-sc" for scan mode or "prepend-path-un" for
> > unload mode).
> >
> > To get the expected behavior, the prepend-path command should be run
> > from current modulefile evaluation context. It could be achieved by
> > changing the module-addpath procedure the following way:
> >
> > proc module-addpath {path} {
> >    # get name of current module Tcl interp
> >    set itrp [getCurrentModfileInterpName]
> >
> >    interp eval $itrp prepend-path MODULEPATH $path
> > }
> >
> > I need to update the documentation to explain that along the
> > siteconfig.tcl modulefile_extra_cmds documentation.
> >
> > Best regards,
> > Xavier
> >
> > Le jeu. 11 sept. 2025 à 06:14, Xavier Delaruelle
> > <xav...@gm...> a écrit :
> >>
> >> Dear Achim,
> >>
> >> Thanks for your message. I can reproduce the issue you describe on my
> >> side. Even when defining the module-addpath procedure within the
> >> modulefile.
> >>
> >> From a first quick analysis, it does not feel that this is the
> >> indented behavior. I will need to investigate further down to find
> >> what is going on.
> >>
> >> Best regards,
> >> Xavier
> >>
> >> Le mer. 10 sept. 2025 à 10:57, Gsell, Achim <ach...@ps...> a écrit :
> >>>
> >>> Dear All,
> >>>
> >>> I'm currently playing with a hierarchical module structure, which is now supported in version 5.6. If I add a new directory to MODULEPATH in a modulefile itself, everything works fine. But as soon as I move the statement
> >>>
> >>>  prepend-path MODULEPATH $something
> >>>
> >>> to a procedure inside my siteconfig.tcl file I run into two issues.
> >>>
> >>> First: The path $something is not removed from MODULEPATH while unloading the module.
> >>>
> >>> Second: module spider —indepth doesn’t show the modules in  $something.
> >>>
> >>> Example:
> >>>
> >>> I have the following (simplified) modulefile for gcc/15.2.0:
> >>>
> >>>  $ cat /afs/psi.ch/group/HPCE/Modules/Programming/modulefiles/gcc/15.2.0
> >>>  #%Module
> >>>
> >>>  module-help "GCC compiler collection"
> >>>  module-addpath {/afs/psi.ch/group/HPCE/Modules/Compiler/modulefiles/gcc/15.2.0}
> >>>
> >>> In my siteconfig.tcl the procedure module-addpath is defined as:
> >>>
> >>>  proc module-addpath { path } {
> >>>      prepend-path MODULEPATH $path
> >>>  }
> >>>
> >>> I have the following modulefiles:
> >>>
> >>>  [gsell@merlin-c-002 ~]$ find /afs/psi.ch/group/HPCE/Modules/*/modulefiles -type f
> >>>  /afs/psi.ch/group/HPCE/Modules/Compiler/modulefiles/gcc/15.2.0/OpenBLAS/0.3.30
> >>>  /afs/psi.ch/group/HPCE/Modules/Programming/modulefiles/gcc/15.2.0
> >>>
> >>> and MODULEPATH is set to:
> >>>
> >>>  [gsell@merlin-c-002 ~]$ echo $MODULEPATH
> >>>  /afs/psi.ch/group/HPCE/Modules/Programming/modulefiles
> >>>
> >>> The spider command should show the OpenBLAS module, but it doesn’t:
> >>>
> >>>  [gsell@merlin-c-002 ~]$ module spider --indepth
> >>>  ------------ /afs/psi.ch/group/HPCE/Modules/Programming/modulefiles -------------
> >>>  gcc/15.2.0
> >>>
> >>>  Key:
> >>>  modulepath
> >>>
> >>> After loading the gcc module, the OpenBLAS module is available, this is correct:
> >>>
> >>>  [gsell@merlin-c-002 ~]$ module load gcc/15.2.0
> >>>  [gsell@merlin-c-002 ~]$ module avail
> >>>  -------- /afs/psi.ch/group/HPCE/Modules/Compiler/modulefiles/gcc/15.2.0 ---------
> >>>  OpenBLAS/0.3.30
> >>>
> >>>  ------------ /afs/psi.ch/group/HPCE/Modules/Programming/modulefiles -------------
> >>>  gcc/15.2.0
> >>>  Key:
> >>>  loaded  modulepath
> >>> But after unloading the gcc module, the OpenBLAS module is still available:
> >>>
> >>>  [gsell@merlin-c-002 ~]$ module unload gcc/15.2.0
> >>>  [gsell@merlin-c-002 ~]$ module avail
> >>>  -------- /afs/psi.ch/group/HPCE/Modules/Compiler/modulefiles/gcc/15.2.0 ---------
> >>>  OpenBLAS/0.3.30
> >>>
> >>>  ------------ /afs/psi.ch/group/HPCE/Modules/Programming/modulefiles -------------
> >>>  gcc/15.2.0
> >>>
> >>>  Key:
> >>>  modulepath
> >>> and the added directory is still in MODULEPATH:
> >>>
> >>>  [gsell@merlin-c-002 ~]$ echo $MODULEPATH
> >>>  /afs/psi.ch/group/HPCE/Modules/Compiler/modulefiles/gcc/15.2.0:/afs/psi.ch/group/HPCE/Modules/Programming/modulefiles
> >>>
> >>>
> >>> If I replace in the gcc/15.2.0 modulefile
> >>>
> >>>  module-addpath {/afs/psi.ch/group/HPCE/Modules/Compiler/modulefiles/gcc/15.2.0}
> >>>
> >>> with
> >>>
> >>>  prepend-path MODULEPATH {/afs/psi.ch/group/HPCE/Modules/Compiler/modulefiles/gcc/15.2.0}
> >>>
> >>> everything works as expected.
> >>>
> >>> I’m not sure whether this behaviour is intended or a bug. If it is intended, how can I add something to MODULEPATH in a procedure?
> >>>
> >>> Best regards,
> >>>
> >>> Achim
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> 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

Dear Xavier,

thanks a lot for the answer and solution!

A little background on why I'm experimenting with this. 

At the Paul Scherrer Institute (PSI), we use Pmodules. Pmodules is essentially a wrapper for Environment Modules 3.2.10 written in Bash. This wrapper implements additional features not available in the old implementation of the Environment Modules. Some of them are now available in the current version, or there is similar functionality available. I started developing Pmodules at a time when the development of the Environment Modules was not progressing. This changed and some of the features in Pmodules - like hierarchical modules - are now available in the Environment Modules. Other features like overlays, Lmod support, availability of modules depending on hostname and/or OS/version are not available. 

Since developing and supporting a special version that is only used at PSI is lot of work, we are considering whether some of the Pmodule for PSI essential extensions could be incorporated into the Tcl Environment Modules. I would like to contribute to the project and have a significant part of my working time available for the implementation of these features.

Best regards 

Achim

> On 12 Sep 2025, at 07:39, Xavier Delaruelle <xav...@gm...> wrote:
> 
> Dear Achim,
> 
> First of all, I made a mistake in my analysis yesterday: defining
> module-addpath procedure within the modulefile works just fine.
> 
> The issue you face comes from the Tcl evaluation context. When defined
> in the siteconfig.tcl, the module-addpath procedure is evaluated in
> the main execution context, not the one specific to modulefile
> evaluation. Thus, modulefile commands like prepend-path called from
> the main context are not the correct one adapted to the current
> evaluation mode ("edit-path-sc" for scan mode or "prepend-path-un" for
> unload mode).
> 
> To get the expected behavior, the prepend-path command should be run
> from current modulefile evaluation context. It could be achieved by
> changing the module-addpath procedure the following way:
> 
> proc module-addpath {path} {
>    # get name of current module Tcl interp
>    set itrp [getCurrentModfileInterpName]
> 
>    interp eval $itrp prepend-path MODULEPATH $path
> }
> 
> I need to update the documentation to explain that along the
> siteconfig.tcl modulefile_extra_cmds documentation.
> 
> Best regards,
> Xavier
> 
> Le jeu. 11 sept. 2025 à 06:14, Xavier Delaruelle
> <xav...@gm...> a écrit :
>> 
>> Dear Achim,
>> 
>> Thanks for your message. I can reproduce the issue you describe on my
>> side. Even when defining the module-addpath procedure within the
>> modulefile.
>> 
>> From a first quick analysis, it does not feel that this is the
>> indented behavior. I will need to investigate further down to find
>> what is going on.
>> 
>> Best regards,
>> Xavier
>> 
>> Le mer. 10 sept. 2025 à 10:57, Gsell, Achim <ach...@ps...> a écrit :
>>> 
>>> Dear All,
>>> 
>>> I'm currently playing with a hierarchical module structure, which is now supported in version 5.6. If I add a new directory to MODULEPATH in a modulefile itself, everything works fine. But as soon as I move the statement
>>> 
>>>  prepend-path MODULEPATH $something
>>> 
>>> to a procedure inside my siteconfig.tcl file I run into two issues.
>>> 
>>> First: The path $something is not removed from MODULEPATH while unloading the module.
>>> 
>>> Second: module spider —indepth doesn’t show the modules in  $something.
>>> 
>>> Example:
>>> 
>>> I have the following (simplified) modulefile for gcc/15.2.0:
>>> 
>>>  $ cat /afs/psi.ch/group/HPCE/Modules/Programming/modulefiles/gcc/15.2.0
>>>  #%Module
>>> 
>>>  module-help "GCC compiler collection"
>>>  module-addpath {/afs/psi.ch/group/HPCE/Modules/Compiler/modulefiles/gcc/15.2.0}
>>> 
>>> In my siteconfig.tcl the procedure module-addpath is defined as:
>>> 
>>>  proc module-addpath { path } {
>>>      prepend-path MODULEPATH $path
>>>  }
>>> 
>>> I have the following modulefiles:
>>> 
>>>  [gsell@merlin-c-002 ~]$ find /afs/psi.ch/group/HPCE/Modules/*/modulefiles -type f
>>>  /afs/psi.ch/group/HPCE/Modules/Compiler/modulefiles/gcc/15.2.0/OpenBLAS/0.3.30
>>>  /afs/psi.ch/group/HPCE/Modules/Programming/modulefiles/gcc/15.2.0
>>> 
>>> and MODULEPATH is set to:
>>> 
>>>  [gsell@merlin-c-002 ~]$ echo $MODULEPATH
>>>  /afs/psi.ch/group/HPCE/Modules/Programming/modulefiles
>>> 
>>> The spider command should show the OpenBLAS module, but it doesn’t:
>>> 
>>>  [gsell@merlin-c-002 ~]$ module spider --indepth
>>>  ------------ /afs/psi.ch/group/HPCE/Modules/Programming/modulefiles -------------
>>>  gcc/15.2.0
>>> 
>>>  Key:
>>>  modulepath
>>> 
>>> After loading the gcc module, the OpenBLAS module is available, this is correct:
>>> 
>>>  [gsell@merlin-c-002 ~]$ module load gcc/15.2.0
>>>  [gsell@merlin-c-002 ~]$ module avail
>>>  -------- /afs/psi.ch/group/HPCE/Modules/Compiler/modulefiles/gcc/15.2.0 ---------
>>>  OpenBLAS/0.3.30
>>> 
>>>  ------------ /afs/psi.ch/group/HPCE/Modules/Programming/modulefiles -------------
>>>  gcc/15.2.0
>>>  Key:
>>>  loaded  modulepath
>>> But after unloading the gcc module, the OpenBLAS module is still available:
>>> 
>>>  [gsell@merlin-c-002 ~]$ module unload gcc/15.2.0
>>>  [gsell@merlin-c-002 ~]$ module avail
>>>  -------- /afs/psi.ch/group/HPCE/Modules/Compiler/modulefiles/gcc/15.2.0 ---------
>>>  OpenBLAS/0.3.30
>>> 
>>>  ------------ /afs/psi.ch/group/HPCE/Modules/Programming/modulefiles -------------
>>>  gcc/15.2.0
>>> 
>>>  Key:
>>>  modulepath
>>> and the added directory is still in MODULEPATH:
>>> 
>>>  [gsell@merlin-c-002 ~]$ echo $MODULEPATH
>>>  /afs/psi.ch/group/HPCE/Modules/Compiler/modulefiles/gcc/15.2.0:/afs/psi.ch/group/HPCE/Modules/Programming/modulefiles
>>> 
>>> 
>>> If I replace in the gcc/15.2.0 modulefile
>>> 
>>>  module-addpath {/afs/psi.ch/group/HPCE/Modules/Compiler/modulefiles/gcc/15.2.0}
>>> 
>>> with
>>> 
>>>  prepend-path MODULEPATH {/afs/psi.ch/group/HPCE/Modules/Compiler/modulefiles/gcc/15.2.0}
>>> 
>>> everything works as expected.
>>> 
>>> I’m not sure whether this behaviour is intended or a bug. If it is intended, how can I add something to MODULEPATH in a procedure?
>>> 
>>> Best regards,
>>> 
>>> Achim
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> 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

Dear Achim,

First of all, I made a mistake in my analysis yesterday: defining
module-addpath procedure within the modulefile works just fine.

The issue you face comes from the Tcl evaluation context. When defined
in the siteconfig.tcl, the module-addpath procedure is evaluated in
the main execution context, not the one specific to modulefile
evaluation. Thus, modulefile commands like prepend-path called from
the main context are not the correct one adapted to the current
evaluation mode ("edit-path-sc" for scan mode or "prepend-path-un" for
unload mode).

To get the expected behavior, the prepend-path command should be run
from current modulefile evaluation context. It could be achieved by
changing the module-addpath procedure the following way:

proc module-addpath {path} {
    # get name of current module Tcl interp
    set itrp [getCurrentModfileInterpName]

    interp eval $itrp prepend-path MODULEPATH $path
}

I need to update the documentation to explain that along the
siteconfig.tcl modulefile_extra_cmds documentation.

Best regards,
Xavier

Le jeu. 11 sept. 2025 à 06:14, Xavier Delaruelle
<xav...@gm...> a écrit :
>
> Dear Achim,
>
> Thanks for your message. I can reproduce the issue you describe on my
> side. Even when defining the module-addpath procedure within the
> modulefile.
>
> From a first quick analysis, it does not feel that this is the
> indented behavior. I will need to investigate further down to find
> what is going on.
>
> Best regards,
> Xavier
>
> Le mer. 10 sept. 2025 à 10:57, Gsell, Achim <ach...@ps...> a écrit :
> >
> > Dear All,
> >
> > I'm currently playing with a hierarchical module structure, which is now supported in version 5.6. If I add a new directory to MODULEPATH in a modulefile itself, everything works fine. But as soon as I move the statement
> >
> >   prepend-path MODULEPATH $something
> >
> > to a procedure inside my siteconfig.tcl file I run into two issues.
> >
> > First: The path $something is not removed from MODULEPATH while unloading the module.
> >
> > Second: module spider —indepth doesn’t show the modules in  $something.
> >
> > Example:
> >
> > I have the following (simplified) modulefile for gcc/15.2.0:
> >
> >   $ cat /afs/psi.ch/group/HPCE/Modules/Programming/modulefiles/gcc/15.2.0
> >   #%Module
> >
> >   module-help "GCC compiler collection"
> >   module-addpath {/afs/psi.ch/group/HPCE/Modules/Compiler/modulefiles/gcc/15.2.0}
> >
> > In my siteconfig.tcl the procedure module-addpath is defined as:
> >
> >   proc module-addpath { path } {
> >       prepend-path MODULEPATH $path
> >   }
> >
> > I have the following modulefiles:
> >
> >   [gsell@merlin-c-002 ~]$ find /afs/psi.ch/group/HPCE/Modules/*/modulefiles -type f
> >   /afs/psi.ch/group/HPCE/Modules/Compiler/modulefiles/gcc/15.2.0/OpenBLAS/0.3.30
> >   /afs/psi.ch/group/HPCE/Modules/Programming/modulefiles/gcc/15.2.0
> >
> > and MODULEPATH is set to:
> >
> >   [gsell@merlin-c-002 ~]$ echo $MODULEPATH
> >   /afs/psi.ch/group/HPCE/Modules/Programming/modulefiles
> >
> > The spider command should show the OpenBLAS module, but it doesn’t:
> >
> >   [gsell@merlin-c-002 ~]$ module spider --indepth
> >   ------------ /afs/psi.ch/group/HPCE/Modules/Programming/modulefiles -------------
> >   gcc/15.2.0
> >
> >   Key:
> >   modulepath
> >
> > After loading the gcc module, the OpenBLAS module is available, this is correct:
> >
> >   [gsell@merlin-c-002 ~]$ module load gcc/15.2.0
> >   [gsell@merlin-c-002 ~]$ module avail
> >   -------- /afs/psi.ch/group/HPCE/Modules/Compiler/modulefiles/gcc/15.2.0 ---------
> >   OpenBLAS/0.3.30
> >
> >   ------------ /afs/psi.ch/group/HPCE/Modules/Programming/modulefiles -------------
> >   gcc/15.2.0
> >   Key:
> >   loaded  modulepath
> > But after unloading the gcc module, the OpenBLAS module is still available:
> >
> >   [gsell@merlin-c-002 ~]$ module unload gcc/15.2.0
> >   [gsell@merlin-c-002 ~]$ module avail
> >   -------- /afs/psi.ch/group/HPCE/Modules/Compiler/modulefiles/gcc/15.2.0 ---------
> >   OpenBLAS/0.3.30
> >
> >   ------------ /afs/psi.ch/group/HPCE/Modules/Programming/modulefiles -------------
> >   gcc/15.2.0
> >
> >   Key:
> >   modulepath
> > and the added directory is still in MODULEPATH:
> >
> >   [gsell@merlin-c-002 ~]$ echo $MODULEPATH
> >   /afs/psi.ch/group/HPCE/Modules/Compiler/modulefiles/gcc/15.2.0:/afs/psi.ch/group/HPCE/Modules/Programming/modulefiles
> >
> >
> > If I replace in the gcc/15.2.0 modulefile
> >
> >   module-addpath {/afs/psi.ch/group/HPCE/Modules/Compiler/modulefiles/gcc/15.2.0}
> >
> > with
> >
> >   prepend-path MODULEPATH {/afs/psi.ch/group/HPCE/Modules/Compiler/modulefiles/gcc/15.2.0}
> >
> > everything works as expected.
> >
> > I’m not sure whether this behaviour is intended or a bug. If it is intended, how can I add something to MODULEPATH in a procedure?
> >
> > Best regards,
> >
> > Achim
> >
> >
> >
> > _______________________________________________
> > Modules-interest mailing list
> > Mod...@li...
> > https://lists.sourceforge.net/lists/listinfo/modules-interest

Dear Achim,

Thanks for your message. I can reproduce the issue you describe on my
side. Even when defining the module-addpath procedure within the
modulefile.

>From a first quick analysis, it does not feel that this is the
indented behavior. I will need to investigate further down to find
what is going on.

Best regards,
Xavier

Le mer. 10 sept. 2025 à 10:57, Gsell, Achim <ach...@ps...> a écrit :
>
> Dear All,
>
> I'm currently playing with a hierarchical module structure, which is now supported in version 5.6. If I add a new directory to MODULEPATH in a modulefile itself, everything works fine. But as soon as I move the statement
>
>   prepend-path MODULEPATH $something
>
> to a procedure inside my siteconfig.tcl file I run into two issues.
>
> First: The path $something is not removed from MODULEPATH while unloading the module.
>
> Second: module spider —indepth doesn’t show the modules in  $something.
>
> Example:
>
> I have the following (simplified) modulefile for gcc/15.2.0:
>
>   $ cat /afs/psi.ch/group/HPCE/Modules/Programming/modulefiles/gcc/15.2.0
>   #%Module
>
>   module-help "GCC compiler collection"
>   module-addpath {/afs/psi.ch/group/HPCE/Modules/Compiler/modulefiles/gcc/15.2.0}
>
> In my siteconfig.tcl the procedure module-addpath is defined as:
>
>   proc module-addpath { path } {
>       prepend-path MODULEPATH $path
>   }
>
> I have the following modulefiles:
>
>   [gsell@merlin-c-002 ~]$ find /afs/psi.ch/group/HPCE/Modules/*/modulefiles -type f
>   /afs/psi.ch/group/HPCE/Modules/Compiler/modulefiles/gcc/15.2.0/OpenBLAS/0.3.30
>   /afs/psi.ch/group/HPCE/Modules/Programming/modulefiles/gcc/15.2.0
>
> and MODULEPATH is set to:
>
>   [gsell@merlin-c-002 ~]$ echo $MODULEPATH
>   /afs/psi.ch/group/HPCE/Modules/Programming/modulefiles
>
> The spider command should show the OpenBLAS module, but it doesn’t:
>
>   [gsell@merlin-c-002 ~]$ module spider --indepth
>   ------------ /afs/psi.ch/group/HPCE/Modules/Programming/modulefiles -------------
>   gcc/15.2.0
>
>   Key:
>   modulepath
>
> After loading the gcc module, the OpenBLAS module is available, this is correct:
>
>   [gsell@merlin-c-002 ~]$ module load gcc/15.2.0
>   [gsell@merlin-c-002 ~]$ module avail
>   -------- /afs/psi.ch/group/HPCE/Modules/Compiler/modulefiles/gcc/15.2.0 ---------
>   OpenBLAS/0.3.30
>
>   ------------ /afs/psi.ch/group/HPCE/Modules/Programming/modulefiles -------------
>   gcc/15.2.0
>   Key:
>   loaded  modulepath
> But after unloading the gcc module, the OpenBLAS module is still available:
>
>   [gsell@merlin-c-002 ~]$ module unload gcc/15.2.0
>   [gsell@merlin-c-002 ~]$ module avail
>   -------- /afs/psi.ch/group/HPCE/Modules/Compiler/modulefiles/gcc/15.2.0 ---------
>   OpenBLAS/0.3.30
>
>   ------------ /afs/psi.ch/group/HPCE/Modules/Programming/modulefiles -------------
>   gcc/15.2.0
>
>   Key:
>   modulepath
> and the added directory is still in MODULEPATH:
>
>   [gsell@merlin-c-002 ~]$ echo $MODULEPATH
>   /afs/psi.ch/group/HPCE/Modules/Compiler/modulefiles/gcc/15.2.0:/afs/psi.ch/group/HPCE/Modules/Programming/modulefiles
>
>
> If I replace in the gcc/15.2.0 modulefile
>
>   module-addpath {/afs/psi.ch/group/HPCE/Modules/Compiler/modulefiles/gcc/15.2.0}
>
> with
>
>   prepend-path MODULEPATH {/afs/psi.ch/group/HPCE/Modules/Compiler/modulefiles/gcc/15.2.0}
>
> everything works as expected.
>
> I’m not sure whether this behaviour is intended or a bug. If it is intended, how can I add something to MODULEPATH in a procedure?
>
> Best regards,
>
> Achim
>
>
>
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest

Dear All,

I'm currently playing with a hierarchical module structure, which is now supported in version 5.6. If I add a new directory to MODULEPATH in a modulefile itself, everything works fine. But as soon as I move the statement

  prepend-path MODULEPATH $something

to a procedure inside my siteconfig.tcl file I run into two issues.

First: The path $something is not removed from MODULEPATH while unloading the module.

Second: module spider —indepth doesn’t show the modules in  $something.

Example:

I have the following (simplified) modulefile for gcc/15.2.0:

  $ cat /afs/psi.ch/group/HPCE/Modules/Programming/modulefiles/gcc/15.2.0 
  #%Module

  module-help "GCC compiler collection"
  module-addpath {/afs/psi.ch/group/HPCE/Modules/Compiler/modulefiles/gcc/15.2.0}

In my siteconfig.tcl the procedure module-addpath is defined as:

  proc module-addpath { path } {
      prepend-path MODULEPATH $path
  }

I have the following modulefiles:

  [gsell@merlin-c-002 ~]$ find /afs/psi.ch/group/HPCE/Modules/*/modulefiles -type f
  /afs/psi.ch/group/HPCE/Modules/Compiler/modulefiles/gcc/15.2.0/OpenBLAS/0.3.30
  /afs/psi.ch/group/HPCE/Modules/Programming/modulefiles/gcc/15.2.0

and MODULEPATH is set to:

  [gsell@merlin-c-002 ~]$ echo $MODULEPATH 
  /afs/psi.ch/group/HPCE/Modules/Programming/modulefiles

The spider command should show the OpenBLAS module, but it doesn’t:

  [gsell@merlin-c-002 ~]$ module spider --indepth 
  ------------ /afs/psi.ch/group/HPCE/Modules/Programming/modulefiles -------------
  gcc/15.2.0  

  Key:
  modulepath  

After loading the gcc module, the OpenBLAS module is available, this is correct:

  [gsell@merlin-c-002 ~]$ module load gcc/15.2.0 
  [gsell@merlin-c-002 ~]$ module avail 
  -------- /afs/psi.ch/group/HPCE/Modules/Compiler/modulefiles/gcc/15.2.0 ---------
  OpenBLAS/0.3.30  

  ------------ /afs/psi.ch/group/HPCE/Modules/Programming/modulefiles -------------
  gcc/15.2.0  
  Key:
  loaded  modulepath 
But after unloading the gcc module, the OpenBLAS module is still available:

  [gsell@merlin-c-002 ~]$ module unload gcc/15.2.0 
  [gsell@merlin-c-002 ~]$ module avail 
  -------- /afs/psi.ch/group/HPCE/Modules/Compiler/modulefiles/gcc/15.2.0 ---------
  OpenBLAS/0.3.30  

  ------------ /afs/psi.ch/group/HPCE/Modules/Programming/modulefiles -------------
  gcc/15.2.0  

  Key:
  modulepath  
and the added directory is still in MODULEPATH:

  [gsell@merlin-c-002 ~]$ echo $MODULEPATH 
  /afs/psi.ch/group/HPCE/Modules/Compiler/modulefiles/gcc/15.2.0:/afs/psi.ch/group/HPCE/Modules/Programming/modulefiles

If I replace in the gcc/15.2.0 modulefile

  module-addpath {/afs/psi.ch/group/HPCE/Modules/Compiler/modulefiles/gcc/15.2.0}

with

  prepend-path MODULEPATH {/afs/psi.ch/group/HPCE/Modules/Compiler/modulefiles/gcc/15.2.0}

everything works as expected.

I’m not sure whether this behaviour is intended or a bug. If it is intended, how can I add something to MODULEPATH in a procedure?

Best regards,

Achim

Dear All,

The Technical Charter of the Modules project has been adopted.

This document is available at:
https://modules.readthedocs.io/en/latest/CHARTER.html

Best regards,
Xavier

Hello All,

I am working on improving the Wikipedia page for Environment Modules.
I have just added a History section to provide an overview of the
project’s development from its origins to the present.

I do not know well what happened on the project before 2008. So if
people remember, please check what I have written and tell me if
something is wrong.

https://en.wikipedia.org/wiki/Environment_Modules_(software)#History

Regards,
Xavier

Hello Paul,

Thanks for your explanation.

I have used your ".obsolete" trick and it works fine.

Best regards,
Laurent.

-----Message d'origine-----
De : Paul Markfort <pau...@gm...> 
Envoyé : samedi 23 août 2025 16:55
À : mod...@li...
Objet : Re: [Modules] module avail is not saying the truth!

I should add:

"module avail" will list the "a/b" module in both locations, but all commands will operate on the first one.
And, I believe, the same is true of the .modulerc file (only the first one found will be used, and it will apply to both module folders "a/" (even if the only .modulerc is in the second folder - it will apply to both).  Xavier can correct me, if I have that wrong.

Hopefully, this clarifies the situation.

I think if you want to deny access to the first module, you might try making it unreadable (chmod a-r ).  I am not sure if that will work - but it is worth a try (otherwise, just rename or remove it).

As a side note, To get rid of an old module, but save it for posterity - I create an .obsolete folder in the module folder and move it there (you can find it, and put it back if you need to).  This hides it from module avail.

Also, if you want to include pictures - that is fine.
But please also include the complete text output in the message as well.

Thanks.

On 2025-08-22 10:15 AM, Paul Markfort wrote:
> Not a bug.
> This behavior goes way back to the Turn of the Century.
> 
> If you have:
> MODULEPATH=/home/user/modules:/usr/etc/modules/common
> 
> And you have the files:
> /home/user/modules/a/b
> /usr/etc/modules/common/a/b
> 
> 
> Only the first module "a/b" will be visible to the modules command.
> 
> I use this "FEATURE" all the time to test changes to existing modules.
> (copy the module from the second path, to the first - then change an modify the copy and test it).
> 
> 
> 
> 
> On 2025-08-22 5:17 AM, Laurent BESSON wrote:
>> Hello dear Modules users,
>>
>> As an introduction, I have to say I did something weird : I have the same module name in 2 places and both are visible to < module > command.
>>
>> Of course, these 2 modules files have a different content. And I wanted to < forbid > one. So I added in a .modulerc the following line :
>>
>> module-forbid --message "This version has been removed" 
>> /media/TmpStore/users/lbesson/Tools/modulefiles/mentor/questa_lint/20
>> 25.2_1
>>
>> When I run < ml avail mentor/questa_lint>, it says (I include a screenshot to keep colors and nice display) :
>>
>> [cid:image001.png@01DC135D.46C53D90]
>>
>> It shows exactly the expected behaviour. But then I try to load the < available > one and I get this :
>>
>> [cid:image002.png@01DC135E.B4DE18A0]
>>
>> To me, it looks like a bug : I should be allowed to load < 
>> mentor/questa_lint/2025.2_1 > from < /tool/modules >
>>
>> What do you think ?
>>
>> Best regards,
>> Laurent.
>>
>> PS : I'm running Modules 5.5 under RedHat machines
>>
>>
>>
>> _______________________________________________
>> Modules-interest mailing list
>> Mod...@li...
>> https://lists.sourceforge.net/lists/listinfo/modules-interest
>>
> 

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

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

I should add:

"module avail" will list the "a/b" module in both locations, but all commands will operate on the first one.
And, I believe, the same is true of the .modulerc file (only the first one found will be used, and it will apply to both module folders "a/" (even if the only .modulerc is in the second folder - it will apply to both).  Xavier can correct me, if I have that wrong.

Hopefully, this clarifies the situation.

I think if you want to deny access to the first module, you might try making it unreadable (chmod a-r ).  I am not sure if that will work - but it is worth a try (otherwise, just rename or remove it).

As a side note, To get rid of an old module, but save it for posterity - I create an .obsolete folder in the module folder and move it there (you can find it, and put it back if you need to).  This hides it from module avail.

Also, if you want to include pictures - that is fine.
But please also include the complete text output in the message as well.

Thanks.

On 2025-08-22 10:15 AM, Paul Markfort wrote:
> Not a bug.
> This behavior goes way back to the Turn of the Century.
> 
> If you have:
> MODULEPATH=/home/user/modules:/usr/etc/modules/common
> 
> And you have the files:
> /home/user/modules/a/b
> /usr/etc/modules/common/a/b
> 
> 
> Only the first module "a/b" will be visible to the modules command.
> 
> I use this "FEATURE" all the time to test changes to existing modules.
> (copy the module from the second path, to the first - then change an modify the copy and test it).
> 
> 
> 
> 
> On 2025-08-22 5:17 AM, Laurent BESSON wrote:
>> Hello dear Modules users,
>>
>> As an introduction, I have to say I did something weird : I have the same module name in 2 places and both are visible to < module > command.
>>
>> Of course, these 2 modules files have a different content. And I wanted to < forbid > one. So I added in a .modulerc the following line :
>>
>> module-forbid --message "This version has been removed" /media/TmpStore/users/lbesson/Tools/modulefiles/mentor/questa_lint/2025.2_1
>>
>> When I run < ml avail mentor/questa_lint>, it says (I include a screenshot to keep colors and nice display) :
>>
>> [cid:image001.png@01DC135D.46C53D90]
>>
>> It shows exactly the expected behaviour. But then I try to load the < available > one and I get this :
>>
>> [cid:image002.png@01DC135E.B4DE18A0]
>>
>> To me, it looks like a bug : I should be allowed to load < mentor/questa_lint/2025.2_1 > from < /tool/modules >
>>
>> What do you think ?
>>
>> Best regards,
>> Laurent.
>>
>> PS : I'm running Modules 5.5 under RedHat machines
>>
>>
>>
>> _______________________________________________
>> Modules-interest mailing list
>> Mod...@li...
>> https://lists.sourceforge.net/lists/listinfo/modules-interest
>>
> 

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

Not a bug.
This behavior goes way back to the Turn of the Century.

If you have:
MODULEPATH=/home/user/modules:/usr/etc/modules/common

And you have the files:
/home/user/modules/a/b
/usr/etc/modules/common/a/b

Only the first module "a/b" will be visible to the modules command.

I use this "FEATURE" all the time to test changes to existing modules.
(copy the module from the second path, to the first - then change an modify the copy and test it).

On 2025-08-22 5:17 AM, Laurent BESSON wrote:
> Hello dear Modules users,
> 
> As an introduction, I have to say I did something weird : I have the same module name in 2 places and both are visible to < module > command.
> 
> Of course, these 2 modules files have a different content. And I wanted to < forbid > one. So I added in a .modulerc the following line :
> 
> module-forbid --message "This version has been removed" /media/TmpStore/users/lbesson/Tools/modulefiles/mentor/questa_lint/2025.2_1
> 
> When I run < ml avail mentor/questa_lint>, it says (I include a screenshot to keep colors and nice display) :
> 
> [cid:image001.png@01DC135D.46C53D90]
> 
> It shows exactly the expected behaviour. But then I try to load the < available > one and I get this :
> 
> [cid:image002.png@01DC135E.B4DE18A0]
> 
> To me, it looks like a bug : I should be allowed to load < mentor/questa_lint/2025.2_1 > from < /tool/modules >
> 
> What do you think ?
> 
> Best regards,
> Laurent.
> 
> PS : I'm running Modules 5.5 under RedHat machines
> 
> 
> 
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest
> 

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

Hello dear Modules users,

As an introduction, I have to say I did something weird : I have the same module name in 2 places and both are visible to < module > command.

Of course, these 2 modules files have a different content. And I wanted to < forbid > one. So I added in a .modulerc the following line :

module-forbid --message "This version has been removed" /media/TmpStore/users/lbesson/Tools/modulefiles/mentor/questa_lint/2025.2_1

When I run < ml avail mentor/questa_lint>, it says (I include a screenshot to keep colors and nice display) :

[cid:image001.png@01DC135D.46C53D90]

It shows exactly the expected behaviour. But then I try to load the < available > one and I get this :

[cid:image002.png@01DC135E.B4DE18A0]

To me, it looks like a bug : I should be allowed to load < mentor/questa_lint/2025.2_1 > from < /tool/modules >

What do you think ?

Best regards,
Laurent.

PS : I'm running Modules 5.5 under RedHat machines

Hello All,

It is a great pleasure to announce that Modules 5.6 is out! Many new
features have been added, the most prominent are:

* spider sub-command
* Requiring via module
* Always see hidden modules
* Issue warning upon module evaluation
* Simplified way to define module help message
* Support for newline character in environment variable value
* Declare additional elements provided by a module

Details on the major changes included in this new release are provided
in the MIGRATING document. The list of all changes made in this new
version are described in the NEWS document.

 http://modules.readthedocs.io/en/stable/MIGRATING.html
 http://modules.readthedocs.io/en/stable/NEWS.html

The tarball of this new version can be downloaded at:

 http://downloads.sourceforge.net/modules/modules-5.6.0.tar.gz

The zipball to install this new version on Windows platform can be
downloaded at:

 http://downloads.sourceforge.net/modules/modules-5.6.0-win.zip

If you encounter any issue, please let us know by creating a ticket on
the project bug tracker at:

 https://github.com/envmodules/modules/issues

Many thanks to Laurent Besson for his contribution to this release.
Many thanks also to all of you who improve Modules by reporting bugs
or sharing new ideas.

Best regards,
Xavier

Dear All,

The upcoming Modules v5.6 release introduces a new configuration
option: require_via.

This option enables the ability to establish a dependency link between
a via module and the modulefiles located in the modulepath it enables.
With require_via activated, Modules can now fully support the module
hierarchy mechanism.

Full details and examples:
https://modules.readthedocs.io/en/latest/MIGRATING.html#requiring-via-module

Regards,
Xavier

1996	Jan	Feb	Mar	Apr	May (1)	Jun (14)	Jul (6)	Aug (7)	Sep (1)	Oct (16)	Nov (9)	Dec (2)
1997	Jan (9)	Feb (1)	Mar (1)	Apr (3)	May (4)	Jun (6)	Jul	Aug (1)	Sep	Oct (3)	Nov	Dec
1998	Jan (5)	Feb (5)	Mar (1)	Apr	May (3)	Jun (1)	Jul	Aug (3)	Sep (6)	Oct (8)	Nov	Dec (1)
1999	Jan (2)	Feb (1)	Mar (2)	Apr (2)	May	Jun (2)	Jul	Aug (10)	Sep (1)	Oct	Nov (6)	Dec (6)
2000	Jan (5)	Feb (19)	Mar (27)	Apr (22)	May (11)	Jun (1)	Jul	Aug (7)	Sep (3)	Oct (1)	Nov (13)	Dec (4)
2001	Jan (14)	Feb	Mar (5)	Apr (9)	May	Jun (5)	Jul (19)	Aug (8)	Sep (4)	Oct (4)	Nov (9)	Dec (17)
2002	Jan (17)	Feb (11)	Mar (5)	Apr (17)	May (17)	Jun (7)	Jul (18)	Aug (10)	Sep (20)	Oct (30)	Nov (3)	Dec (2)
2003	Jan (8)	Feb	Mar (2)	Apr	May (16)	Jun (35)	Jul (2)	Aug (4)	Sep (10)	Oct (45)	Nov (7)	Dec (13)
2004	Jan	Feb	Mar (3)	Apr (5)	May (3)	Jun (11)	Jul (1)	Aug (2)	Sep (34)	Oct (26)	Nov (32)	Dec
2005	Jan (11)	Feb (2)	Mar (6)	Apr (60)	May (21)	Jun (14)	Jul (3)	Aug (6)	Sep (6)	Oct (13)	Nov (10)	Dec (19)
2006	Jan (32)	Feb (36)	Mar (7)	Apr (24)	May (5)	Jun (10)	Jul (4)	Aug (17)	Sep (13)	Oct (12)	Nov (1)	Dec (7)
2007	Jan (21)	Feb (16)	Mar (19)	Apr (2)	May (15)	Jun (18)	Jul (6)	Aug (2)	Sep (33)	Oct (21)	Nov	Dec
2008	Jan (10)	Feb (6)	Mar (2)	Apr (6)	May	Jun (13)	Jul (7)	Aug (12)	Sep (22)	Oct (8)	Nov (1)	Dec (25)
2009	Jan (6)	Feb (9)	Mar (13)	Apr (15)	May (17)	Jun (6)	Jul (7)	Aug	Sep (9)	Oct (28)	Nov (6)	Dec
2010	Jan (17)	Feb (3)	Mar	Apr (2)	May (20)	Jun (3)	Jul (9)	Aug (18)	Sep (10)	Oct (8)	Nov (9)	Dec (2)
2011	Jan (9)	Feb (4)	Mar (9)	Apr (7)	May (9)	Jun (31)	Jul (9)	Aug (15)	Sep (17)	Oct (7)	Nov (31)	Dec (2)
2012	Jan (16)	Feb (14)	Mar (59)	Apr (36)	May (28)	Jun (17)	Jul (6)	Aug (12)	Sep (21)	Oct (38)	Nov (14)	Dec (8)
2013	Jan (22)	Feb (8)	Mar (16)	Apr (50)	May (8)	Jun (44)	Jul (22)	Aug (7)	Sep (6)	Oct (5)	Nov (10)	Dec (1)
2014	Jan (1)	Feb (4)	Mar (16)	Apr (11)	May (24)	Jun (22)	Jul (32)	Aug (5)	Sep (5)	Oct (3)	Nov (15)	Dec (6)
2015	Jan (1)	Feb (33)	Mar (10)	Apr (2)	May (2)	Jun (8)	Jul (14)	Aug (4)	Sep (6)	Oct (1)	Nov (14)	Dec (8)
2016	Jan (8)	Feb	Mar	Apr	May (4)	Jun	Jul (8)	Aug (18)	Sep (3)	Oct	Nov (4)	Dec
2017	Jan (1)	Feb (8)	Mar (32)	Apr (31)	May (23)	Jun (1)	Jul (7)	Aug (28)	Sep (17)	Oct (18)	Nov (16)	Dec (17)
2018	Jan (6)	Feb (26)	Mar (6)	Apr (15)	May (22)	Jun (11)	Jul (12)	Aug (28)	Sep (7)	Oct (22)	Nov (21)	Dec (10)
2019	Jan (12)	Feb (23)	Mar (4)	Apr (17)	May (29)	Jun (5)	Jul (15)	Aug (12)	Sep (21)	Oct (17)	Nov (9)	Dec (8)
2020	Jan (11)	Feb (14)	Mar (28)	Apr (2)	May (2)	Jun (9)	Jul (5)	Aug (2)	Sep (7)	Oct (5)	Nov (1)	Dec (7)
2021	Jan (5)	Feb (11)	Mar (6)	Apr (1)	May (10)	Jun (21)	Jul (21)	Aug (8)	Sep (4)	Oct (37)	Nov (4)	Dec
2022	Jan (27)	Feb	Mar (34)	Apr (41)	May (3)	Jun (18)	Jul (16)	Aug (5)	Sep (1)	Oct (3)	Nov (9)	Dec
2023	Jan (13)	Feb (2)	Mar (2)	Apr (18)	May (4)	Jun (9)	Jul (3)	Aug (3)	Sep (6)	Oct (6)	Nov (4)	Dec (3)
2024	Jan (8)	Feb (13)	Mar (1)	Apr (5)	May (4)	Jun (11)	Jul (3)	Aug (7)	Sep (5)	Oct (6)	Nov (9)	Dec (20)
2025	Jan (40)	Feb (27)	Mar (4)	Apr (2)	May (15)	Jun (14)	Jul (3)	Aug (5)	Sep (8)	Oct (11)	Nov	Dec

modules-interest Mailing List for Environment Modules

Manage your shell environment variables and aliases

modules-interest — Discussion forum for modules usage.