modules-interest — Discussion forum for modules usage.

Re: [Modules] Problems with hierarchical modules

[Gsell, A. <ach...@ps...>]

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

Re: [Modules] Problems with hierarchical modules

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

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

Re: [Modules] Problems with hierarchical modules

[Gsell, A. <ach...@ps...>]

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

Re: [Modules] Problems with hierarchical modules

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

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

Re: [Modules] Problems with hierarchical modules

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

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] Problems with hierarchical modules

[Gsell, A. <ach...@ps...>]

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] Technical Charter adopted

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

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

[Modules] Environment Modules wikipedia page

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

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

Re: [Modules] module avail is not saying the truth!

[Laurent B. <lau...@ea...>]

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

Re: [Modules] module avail is not saying the truth!

[Paul M. <pau...@gm...>]

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

Re: [Modules] module avail is not saying the truth!

[Paul M. <pau...@gm...>]

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

[Modules] module avail is not saying the truth!

[Laurent B. <lau...@ea...>]

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] Modules 5.6.0 released

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

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

[Modules] Requiring *via* modules

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

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

[Modules] spider sub-command

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

Dear All,

The upcoming Modules 5.6 release will ship a new sub-command: spider.

This sub-command command lists all available modules not only in the
currently enabled modulepaths, but also recursively in any modulepaths
enabled by those modules.

See the following link for details and examples:
https://modules.readthedocs.io/en/latest/MIGRATING.html#spider-sub-command

Regards,
Xavier

[Modules] New provide modulefile command

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

Dear All,

The upcoming Modules v5.6 release introduces a new "provide"
modulefile command that allows a module to declare additional elements
it offers. These elements are registered as aliases when the module is
loaded, helping fulfill dependencies expressed by other modules.

Full details and examples:
https://modules.readthedocs.io/en/latest/MIGRATING.html#declare-additional-elements-provided-by-a-module

Best regards,
Xavier

[Modules] Always see hidden modules

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

Dear All,

Next version (5.6) will come with the ability to always see hidden
modules, through the addition of the "hidden" element to the output
configuration options:

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

Best regards,
Xavier

Re: [Modules] Modulefiles mode for Emacs

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

Hello All,

Thanks to the contribution of Laurent, a "modulefile-mode" for Emacs
is now available with Modules.

See https://github.com/envmodules/modules/tree/main/share/emacs/lisp

I have adapted RPM spec file to include these Emacs addon files when
installation environment-modules RPM.

Best regards,
Xavier

Le jeu. 12 juin 2025 à 20:29, Xavier Delaruelle
<xav...@gm...> a écrit :
>
> Hello Laurent,
>
> I suggest you create a pull request on GitHub (fork+new
> branch+push+create pull request). Add the new file into directory
> "share/emacs".
>
> Best regards,
> Xavier
>
> Le jeu. 12 juin 2025 à 13:51, Laurent BESSON
> <lau...@ea...> a écrit :
> >
> > Hello Xavier, all
> >
> >
> >
> > I wrote a first version for a Modulefiles mode for Emacs. It relies on existing Tcl mode (tcl-mode) and adds highlighting for the Modulefiles commands.
> >
> >
> >
> > How can we proceed to make it available to anyone ? Do I create a new branch/fork from GitHub or do I send the file (only one, for the time being) directly to you for integration ?
> >
> > If anyone on the list wants to give it a try, I'll be happy to share 😊
> >
> >
> >
> >
> >
> > L.
> >
> >
> >
> > -----Message d'origine-----
> > De : Xavier Delaruelle <xav...@gm...>
> > Envoyé : mercredi 11 juin 2025 18:49
> > À : Environment Modules usage and discussion. <mod...@li...>
> > Objet : Re: [Modules] Modulefiles mode for Emacs
> >
> >
> >
> > Hello Laurent and All,
> >
> >
> >
> > That could be great stuff to contribute to the project. I am not an Emacs user, so I cannot help here. LLM may help but it requires someone with good enough Emacs knowledge to steer it.
> >
> >
> >
> > For Vim, we have already done this job. It is available within https://github.com/envmodules/modules/tree/main/share/vim.
> >
> >
> >
> > Best regards,
> >
> > Xavier
> >
> >
> >
> > Le mer. 11 juin 2025 à 11:58, Laurent BESSON <lau...@ea...> a écrit :
> >
> > >
> >
> > > Hello dear Modules list,
> >
> > >
> >
> > >
> >
> > >
> >
> > > I’m an old fashion guy and I’m still using Emacs as my favorite editor 😊. But I’m pretty sure I’m not the only one in this list.
> >
> > >
> >
> > >
> >
> > >
> >
> > > I was wondering if someone had developped a « mode » to colorize Modulefiles files ? or at least some setup to recognize Modulefiles and use tcl-mode automatically ?
> >
> > >
> >
> > >
> >
> > >
> >
> > > Best regards,
> >
> > >
> >
> > > Laurent.
> >
> > >
> >
> > > _______________________________________________
> >
> > > 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] envml

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

Thanks for the feedback, I have improved the description a bit.

Best regards,
Xavier

Le ven. 13 juin 2025 à 16:35, Paul Markfort <pau...@gm...> a écrit :
>
> It is a bash script (included with modules).
>
> So it starts a new process - then runs its commands - exiting when done.
>
> Alternatively, you could just write a bash script for the particular situation that loads modules and then runs a command.
>
>
> On 2025-06-13 6:50 AM, InfnPi wrote:
> > I read documentation, but don’t really understand it’s use.
> > What happens after the command is executed?
> > The loaded modules stay or they are just used to run the command and then unloaded?
> >
> > Would be nice to have a “real” usage example with environment before and after the command
> >
> > Roberto
> > On 13 Jun 2025 at 07:56 +0200, Xavier Delaruelle <xav...@gm...>, wrote:
> >> Dear All,
> >>
> >> Do you know the "envml" command?
> >>
> >> Like "env", it runs a program in a modified environment, but here
> >> environment is modified by Modules.
> >>
> >> "envml" is available since Modules 4.0 and it is freshly documented in
> >> its own man page:
> >> https://modules.readthedocs.io/en/latest/envml.html
> >>
> >> Best regards,
> >> Xavier
> >>
> >>
> >> _______________________________________________
> >> 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
> >
>
> --
> --------------------------------------------------------
> 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

Re: [Modules] envml

[Paul M. <pau...@gm...>]

It is a bash script (included with modules).

So it starts a new process - then runs its commands - exiting when done.

Alternatively, you could just write a bash script for the particular situation that loads modules and then runs a command.


On 2025-06-13 6:50 AM, InfnPi wrote:
> I read documentation, but don’t really understand it’s use.
> What happens after the command is executed?
> The loaded modules stay or they are just used to run the command and then unloaded?
> 
> Would be nice to have a “real” usage example with environment before and after the command
> 
> Roberto
> On 13 Jun 2025 at 07:56 +0200, Xavier Delaruelle <xav...@gm...>, wrote:
>> Dear All,
>>
>> Do you know the "envml" command?
>>
>> Like "env", it runs a program in a modified environment, but here
>> environment is modified by Modules.
>>
>> "envml" is available since Modules 4.0 and it is freshly documented in
>> its own man page:
>> https://modules.readthedocs.io/en/latest/envml.html
>>
>> Best regards,
>> Xavier
>>
>>
>> _______________________________________________
>> 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
> 

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

[InfnPi <rob...@pi...>]

I read documentation, but don’t really understand it’s use.
What happens after the command is executed?
The loaded modules stay or they are just used to run the command and then unloaded?

Would be nice to have a “real” usage example with environment before and after the command

Roberto
On 13 Jun 2025 at 07:56 +0200, Xavier Delaruelle <xav...@gm...>, wrote:
> Dear All,
>
> Do you know the "envml" command?
>
> Like "env", it runs a program in a modified environment, but here
> environment is modified by Modules.
>
> "envml" is available since Modules 4.0 and it is freshly documented in
> its own man page:
> https://modules.readthedocs.io/en/latest/envml.html
>
> Best regards,
> Xavier
>
>
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest

[Modules] envml

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

Dear All,

Do you know the "envml" command?

Like "env", it runs a program in a modified environment, but here
environment is modified by Modules.

"envml" is available since Modules 4.0 and it is freshly documented in
its own man page:
  https://modules.readthedocs.io/en/latest/envml.html

Best regards,
Xavier

Re: [Modules] Modulefiles mode for Emacs

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

Hello Laurent,

I suggest you create a pull request on GitHub (fork+new
branch+push+create pull request). Add the new file into directory
"share/emacs".

Best regards,
Xavier

Le jeu. 12 juin 2025 à 13:51, Laurent BESSON
<lau...@ea...> a écrit :
>
> Hello Xavier, all
>
>
>
> I wrote a first version for a Modulefiles mode for Emacs. It relies on existing Tcl mode (tcl-mode) and adds highlighting for the Modulefiles commands.
>
>
>
> How can we proceed to make it available to anyone ? Do I create a new branch/fork from GitHub or do I send the file (only one, for the time being) directly to you for integration ?
>
> If anyone on the list wants to give it a try, I'll be happy to share 😊
>
>
>
>
>
> L.
>
>
>
> -----Message d'origine-----
> De : Xavier Delaruelle <xav...@gm...>
> Envoyé : mercredi 11 juin 2025 18:49
> À : Environment Modules usage and discussion. <mod...@li...>
> Objet : Re: [Modules] Modulefiles mode for Emacs
>
>
>
> Hello Laurent and All,
>
>
>
> That could be great stuff to contribute to the project. I am not an Emacs user, so I cannot help here. LLM may help but it requires someone with good enough Emacs knowledge to steer it.
>
>
>
> For Vim, we have already done this job. It is available within https://github.com/envmodules/modules/tree/main/share/vim.
>
>
>
> Best regards,
>
> Xavier
>
>
>
> Le mer. 11 juin 2025 à 11:58, Laurent BESSON <lau...@ea...> a écrit :
>
> >
>
> > Hello dear Modules list,
>
> >
>
> >
>
> >
>
> > I’m an old fashion guy and I’m still using Emacs as my favorite editor 😊. But I’m pretty sure I’m not the only one in this list.
>
> >
>
> >
>
> >
>
> > I was wondering if someone had developped a « mode » to colorize Modulefiles files ? or at least some setup to recognize Modulefiles and use tcl-mode automatically ?
>
> >
>
> >
>
> >
>
> > Best regards,
>
> >
>
> > Laurent.
>
> >
>
> > _______________________________________________
>
> > 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] Modulefiles mode for Emacs

[Laurent B. <lau...@ea...>]

Hello Xavier, all



I wrote a first version for a Modulefiles mode for Emacs. It relies on existing Tcl mode (tcl-mode) and adds highlighting for the Modulefiles commands.



How can we proceed to make it available to anyone ? Do I create a new branch/fork from GitHub or do I send the file (only one, for the time being) directly to you for integration ?

If anyone on the list wants to give it a try, I'll be happy to share 😊





L.



-----Message d'origine-----
De : Xavier Delaruelle <xav...@gm...>
Envoyé : mercredi 11 juin 2025 18:49
À : Environment Modules usage and discussion. <mod...@li...>
Objet : Re: [Modules] Modulefiles mode for Emacs



Hello Laurent and All,



That could be great stuff to contribute to the project. I am not an Emacs user, so I cannot help here. LLM may help but it requires someone with good enough Emacs knowledge to steer it.



For Vim, we have already done this job. It is available within https://github.com/envmodules/modules/tree/main/share/vim.



Best regards,

Xavier



Le mer. 11 juin 2025 à 11:58, Laurent BESSON <lau...@ea...<mailto:lau...@ea...>> a écrit :

>

> Hello dear Modules list,

>

>

>

> I’m an old fashion guy and I’m still using Emacs as my favorite editor 😊. But I’m pretty sure I’m not the only one in this list.

>

>

>

> I was wondering if someone had developped a « mode » to colorize Modulefiles files ? or at least some setup to recognize Modulefiles and use tcl-mode automatically ?

>

>

>

> Best regards,

>

> Laurent.

>

> _______________________________________________

> Modules-interest mailing list

> Mod...@li...<mailto:Mod...@li...>

> https://lists.sourceforge.net/lists/listinfo/modules-interest





_______________________________________________

Modules-interest mailing list

Mod...@li...<mailto:Mod...@li...>

https://lists.sourceforge.net/lists/listinfo/modules-interest

Re: [Modules] Modulefiles mode for Emacs

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

Hello Laurent and All,

That could be great stuff to contribute to the project. I am not an
Emacs user, so I cannot help here. LLM may help but it requires
someone with good enough Emacs knowledge to steer it.

For Vim, we have already done this job. It is available within
https://github.com/envmodules/modules/tree/main/share/vim.

Best regards,
Xavier

Le mer. 11 juin 2025 à 11:58, Laurent BESSON
<lau...@ea...> a écrit :
>
> Hello dear Modules list,
>
>
>
> I’m an old fashion guy and I’m still using Emacs as my favorite editor 😊. But I’m pretty sure I’m not the only one in this list.
>
>
>
> I was wondering if someone had developped a « mode » to colorize Modulefiles files ? or at least some setup to recognize Modulefiles and use tcl-mode automatically ?
>
>
>
> Best regards,
>
> Laurent.
>
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest