modules-interest — Discussion forum for modules usage.

Re: [Modules] unload/load versus switch

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

Hello Laurent,

Root name is set as "[lindex [file split $modname] 0]", so it is the
word before the first / character.

I will clarify that in the module switch documentation.

Best,
Xavier

Le mer. 19 nov. 2025 à 02:39, Laurent BESSON
<lau...@ea...> a écrit :
>
> Maybe documentation could be more clear on what is actually a « root name ».
>
>
>
> From my initial understanding, when I source the following lines :
>
>
>
> module switch others/texlive/2022
>
> module switch others/nodejs/16.17.1
>
>
>
> I was expexting the root name of these two modules to be respectively :
>
>
>
> others/texlive
>
> others/nodejs
>
>
>
> So the second « module switch others/nodejs/16.17.1» command was not supposed to « unload » the first module « others/texlive/2022 » as they do not share the same « root name »
>
>
>
> Apparently, I’m wrong. What is the real algorithm to define the « root name » of a module ?
>
>
>
> Best regards,
>
> Laurent.
>
>
>
> De : Xavier Delaruelle <xav...@gm...>
> Envoyé : mardi 18 novembre 2025 17:28
> À : Environment Modules usage and discussion. <mod...@li...>
> Objet : Re: [Modules] unload/load versus switch
>
>
>
> Hello Laurent
>
>
>
> This is due to the fact that your modules share same apps or others root name.
>
>
>
> If you enable the new conflict_unload option you may simply module loaded the target module.
>
>
>
> Cheers,
>
> Xavier
>
>
>
> Le mar. 18 nov. 2025, 10:16, Laurent BESSON <lau...@ea...> a écrit :
>
> Hello dear Modules community,
>
>
>
> Naively, I thought « module switch » would be a nice , more compact, way of writing « module unload / module load ». But either I stumbled on a bug or Modules does not work as I expected 😊
>
>
>
> Here is the context. I was previously sourcing this script :
>
>
>
> module unload  others/texlive
>
> module load others/texlive
>
>
>
> module unload apps/python
>
> module load apps/python/3.9.6
>
>
>
> module unload apps/fltExport
>
> module load apps/fltExport/v2.017
>
>
>
> module unload others/nodejs
>
> module load others/nodejs/16.17 .1
>
>
>
> So I thought it would be nice, more readable, to write it this way :
>
>
>
> module switch others/texlive/2022
>
> module switch apps/python/3.9.6
>
> module switch apps/fltExport/v2.017
>
> module switch others/nodejs/16.17.1
>
>
>
> But, when starting from a fresh terminal where no tool has been set, It ends up with these 2 modules only:
>
>
>
> … 1) apps/fltExport/v2.017   2) others/nodejs/16.17.1
>
>
>
> I was expecting to have loaded also « others/texlive » and « apps/python/3.9.6 ».
>
>
>
> So I read the documentation with more attention on the « switch » command. It says :
>
>
>
> Switch loaded modulefile1 with modulefile2. If modulefile1 is not specified, then it is assumed to be the currently loaded module with the same root name as modulefile2.
>
>
>
> So it seems that when I run « module switch apps/fltExport/v2.017 », it unload the first module that match the « root name »and it unloads« apps » thus unload « apps/python/3.9.6 »
>
>
>
> Do I understand it correctly ? Is it the expected behavior ?
>
> In fact, I thought Modules would try to unload « apps/fltExport/<any version> » when running « module switch apps/fltExport/v2.017 ».
>
>
>
> What do you think ?
>
>
>
> Best regards,
>
> Laurent.
>
>
>
> PS : I found an intermediate syntax that works :
>
>
>
> module switch others/texlive others/texlive/2022
>
> module switch apps/python    apps/python/3.9.6
>
> module switch apps/fltExport apps/fltExport/v2.017
>
> module switch others/nodejs  others/nodejs/16.17.1
>
> _______________________________________________
> 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] unload/load versus switch

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

Maybe documentation could be more clear on what is actually a « root name ».

From my initial understanding, when I source the following lines :

module switch others/texlive/2022
module switch others/nodejs/16.17.1

I was expexting the root name of these two modules to be respectively :

others/texlive
others/nodejs

So the second « module switch others/nodejs/16.17.1» command was not supposed to « unload » the first module « others/texlive/2022 » as they do not share the same « root name »

Apparently, I’m wrong. What is the real algorithm to define the « root name » of a module ?

Best regards,
Laurent.

De : Xavier Delaruelle <xav...@gm...>
Envoyé : mardi 18 novembre 2025 17:28
À : Environment Modules usage and discussion. <mod...@li...>
Objet : Re: [Modules] unload/load versus switch

Hello Laurent

This is due to the fact that your modules share same apps or others root name.

If you enable the new conflict_unload option you may simply module loaded the target module.

Cheers,
Xavier

Le mar. 18 nov. 2025, 10:16, Laurent BESSON <lau...@ea...<mailto:lau...@ea...>> a écrit :
Hello dear Modules community,

Naively, I thought « module switch » would be a nice , more compact, way of writing « module unload / module load ». But either I stumbled on a bug or Modules does not work as I expected 😊

Here is the context. I was previously sourcing this script :

module unload  others/texlive
module load others/texlive

module unload apps/python
module load apps/python/3.9.6

module unload apps/fltExport
module load apps/fltExport/v2.017

module unload others/nodejs
module load others/nodejs/16.17 .1

So I thought it would be nice, more readable, to write it this way :

module switch others/texlive/2022
module switch apps/python/3.9.6
module switch apps/fltExport/v2.017
module switch others/nodejs/16.17.1

But, when starting from a fresh terminal where no tool has been set, It ends up with these 2 modules only:

… 1) apps/fltExport/v2.017   2) others/nodejs/16.17.1

I was expecting to have loaded also « others/texlive » and « apps/python/3.9.6 ».

So I read the documentation with more attention on the « switch » command. It says :

Switch loaded modulefile1 with modulefile2. If modulefile1 is not specified, then it is assumed to be the currently loaded module with the same root name as modulefile2.

So it seems that when I run « module switch apps/fltExport/v2.017 », it unload the first module that match the « root name »and it unloads« apps » thus unload « apps/python/3.9.6 »

Do I understand it correctly ? Is it the expected behavior ?
In fact, I thought Modules would try to unload « apps/fltExport/<any version> » when running « module switch apps/fltExport/v2.017 ».

What do you think ?

Best regards,
Laurent.

PS : I found an intermediate syntax that works :

module switch others/texlive others/texlive/2022
module switch apps/python    apps/python/3.9.6
module switch apps/fltExport apps/fltExport/v2.017
module switch others/nodejs  others/nodejs/16.17.1
_______________________________________________
Modules-interest mailing list
Mod...@li...<mailto:Mod...@li...>
https://lists.sourceforge.net/lists/listinfo/modules-interest

Re: [Modules] unload/load versus switch

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

Hello Paul,



Thanks for your reply. We are in line! This is exactly what I wrote in my postscriptum 😊



Best regards,

Laurent



-----Message d'origine-----
De : Paul Markfort <pau...@gm...>
Envoyé : mardi 18 novembre 2025 17:32
À : mod...@li...
Objet : Re: [Modules] unload/load versus switch



You could try this:



module switch others/texlive others/texlive/2022 module switch apps/python apps/python/3.9.6 module switch apps/fltExport apps/fltExport/v2.017 module switch others/nodejs others/nodejs/16.17.1





You might have to use module switch -f, if the first module might not be loaded.







On 2025-11-18 10:15 AM, Laurent BESSON wrote:

> Hello dear Modules community,

>

> Naively, I thought « module switch » would be a nice , more compact,

> way of writing « module unload / module load ». But either I stumbled

> on a bug or Modules does not work as I expected 😊

>

> Here is the context. I was previously sourcing this script :

>

> module unload  others/texlive

> module load others/texlive

>

> module unload apps/python

> module load apps/python/3.9.6

>

> module unload apps/fltExport

> module load apps/fltExport/v2.017

>

> module unload others/nodejs

> module load others/nodejs/16.17 .1

>

> So I thought it would be nice, more readable, to write it this way :

>

> module switch others/texlive/2022

> module switch apps/python/3.9.6

> module switch apps/fltExport/v2.017

> module switch others/nodejs/16.17.1

>

> But, when starting from a fresh terminal where no tool has been set, It ends up with these 2 modules only:

>

> … 1) apps/fltExport/v2.017   2) others/nodejs/16.17.1

>

> I was expecting to have loaded also « others/texlive » and « apps/python/3.9.6 ».

>

> So I read the documentation with more attention on the « switch » command. It says :

>

> Switch loaded modulefile1 with modulefile2. If modulefile1 is not specified, then it is assumed to be the currently loaded module with the same root name as modulefile2.

>

> So it seems that when I run « module switch apps/fltExport/v2.017 »,

> it unload the first module that match the « root name »and it unloads«

> apps » thus unload « apps/python/3.9.6 »

>

> Do I understand it correctly ? Is it the expected behavior ?

> In fact, I thought Modules would try to unload « apps/fltExport/<any version> » when running « module switch apps/fltExport/v2.017 ».

>

> What do you think ?

>

> Best regards,

> Laurent.

>

> PS : I found an intermediate syntax that works :

>

> module switch others/texlive others/texlive/2022

> module switch apps/python    apps/python/3.9.6

> module switch apps/fltExport apps/fltExport/v2.017 module switch

> others/nodejs  others/nodejs/16.17.1

>

>

> This body part will be downloaded on demand.

>

>

> This body part will be downloaded on demand.

>



--

--------------------------------------------------------

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...<mailto:Mod...@li...>

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

Re: [Modules] unload/load versus switch

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

You could try this:

module switch others/texlive others/texlive/2022
module switch apps/python apps/python/3.9.6
module switch apps/fltExport apps/fltExport/v2.017
module switch others/nodejs others/nodejs/16.17.1


You might have to use module switch -f, if the first module might not be loaded.



On 2025-11-18 10:15 AM, Laurent BESSON wrote:
> Hello dear Modules community,
> 
> Naively, I thought « module switch » would be a nice , more compact, way of writing « module unload / module load ». But either I stumbled on a bug or Modules does not work as I expected 😊
> 
> Here is the context. I was previously sourcing this script :
> 
> module unload  others/texlive
> module load others/texlive
> 
> module unload apps/python
> module load apps/python/3.9.6
> 
> module unload apps/fltExport
> module load apps/fltExport/v2.017
> 
> module unload others/nodejs
> module load others/nodejs/16.17 .1
> 
> So I thought it would be nice, more readable, to write it this way :
> 
> module switch others/texlive/2022
> module switch apps/python/3.9.6
> module switch apps/fltExport/v2.017
> module switch others/nodejs/16.17.1
> 
> But, when starting from a fresh terminal where no tool has been set, It ends up with these 2 modules only:
> 
> … 1) apps/fltExport/v2.017   2) others/nodejs/16.17.1
> 
> I was expecting to have loaded also « others/texlive » and « apps/python/3.9.6 ».
> 
> So I read the documentation with more attention on the « switch » command. It says :
> 
> Switch loaded modulefile1 with modulefile2. If modulefile1 is not specified, then it is assumed to be the currently loaded module with the same root name as modulefile2.
> 
> So it seems that when I run « module switch apps/fltExport/v2.017 », it unload the first module that match the « root name »and it unloads« apps » thus unload « apps/python/3.9.6 »
> 
> Do I understand it correctly ? Is it the expected behavior ?
> In fact, I thought Modules would try to unload « apps/fltExport/<any version> » when running « module switch apps/fltExport/v2.017 ».
> 
> What do you think ?
> 
> Best regards,
> Laurent.
> 
> PS : I found an intermediate syntax that works :
> 
> module switch others/texlive others/texlive/2022
> module switch apps/python    apps/python/3.9.6
> module switch apps/fltExport apps/fltExport/v2.017
> module switch others/nodejs  others/nodejs/16.17.1
> 
> 
> This body part will be downloaded on demand.
> 
> 
> This body part will be downloaded on demand.
> 

-- 
--------------------------------------------------------
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] unload/load versus switch

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

Hello Laurent

This is due to the fact that your modules share same apps or others root
name.

If you enable the new conflict_unload option you may simply module loaded
the target module.

Cheers,
Xavier

Le mar. 18 nov. 2025, 10:16, Laurent BESSON <lau...@ea...> a
écrit :

> Hello dear Modules community,
>
>
>
> Naively, I thought « module switch » would be a nice , more compact, way
> of writing « module unload / module load ». But either I stumbled on a bug
> or Modules does not work as I expected 😊
>
>
>
> Here is the context. I was previously sourcing this script :
>
>
>
> module unload  others/texlive
>
> module load others/texlive
>
>
>
> module unload apps/python
>
> module load apps/python/3.9.6
>
>
>
> module unload apps/fltExport
>
> module load apps/fltExport/v2.017
>
>
>
> module unload others/nodejs
>
> module load others/nodejs/16.17 .1
>
>
>
> So I thought it would be nice, more readable, to write it this way :
>
>
>
> module switch others/texlive/2022
>
> module switch apps/python/3.9.6
>
> module switch apps/fltExport/v2.017
>
> module switch others/nodejs/16.17.1
>
>
>
> But, when starting from a fresh terminal where no tool has been set, It
> ends up with these 2 modules only:
>
>
>
> … 1) apps/fltExport/v2.017   2) others/nodejs/16.17.1
>
>
>
> I was expecting to have loaded also « others/texlive » and
> « apps/python/3.9.6 ».
>
>
>
> So I read the documentation with more attention on the « switch » command.
> It says :
>
>
>
> Switch loaded *modulefile1* with *modulefile2*. If *modulefile1* is not
> specified, then it is assumed to be the currently loaded module with *the
> same root name* as *modulefile2*.
>
>
>
> So it seems that when I run « module switch apps/fltExport/v2.017 », it
> unload the first module that match the « root name »and it unloads« apps »
> thus unload « apps/python/3.9.6 »
>
>
>
> Do I understand it correctly ? Is it the expected behavior ?
>
> In fact, I thought Modules would try to unload « apps/fltExport/<any
> version> » when running « module switch apps/fltExport/v2.017 ».
>
>
>
> What do you think ?
>
>
>
> Best regards,
>
> Laurent.
>
>
>
> PS : I found an intermediate syntax that works :
>
>
>
> module switch others/texlive others/texlive/2022
>
> module switch apps/python    apps/python/3.9.6
>
> module switch apps/fltExport apps/fltExport/v2.017
>
> module switch others/nodejs  others/nodejs/16.17.1
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest
>

[Modules] unload/load versus switch

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

Hello dear Modules community,

Naively, I thought « module switch » would be a nice , more compact, way of writing « module unload / module load ». But either I stumbled on a bug or Modules does not work as I expected 😊

Here is the context. I was previously sourcing this script :

module unload  others/texlive
module load others/texlive

module unload apps/python
module load apps/python/3.9.6

module unload apps/fltExport
module load apps/fltExport/v2.017

module unload others/nodejs
module load others/nodejs/16.17 .1

So I thought it would be nice, more readable, to write it this way :

module switch others/texlive/2022
module switch apps/python/3.9.6
module switch apps/fltExport/v2.017
module switch others/nodejs/16.17.1

But, when starting from a fresh terminal where no tool has been set, It ends up with these 2 modules only:

… 1) apps/fltExport/v2.017   2) others/nodejs/16.17.1

I was expecting to have loaded also « others/texlive » and « apps/python/3.9.6 ».

So I read the documentation with more attention on the « switch » command. It says :

Switch loaded modulefile1 with modulefile2. If modulefile1 is not specified, then it is assumed to be the currently loaded module with the same root name as modulefile2.

So it seems that when I run « module switch apps/fltExport/v2.017 », it unload the first module that match the « root name »and it unloads« apps » thus unload « apps/python/3.9.6 »

Do I understand it correctly ? Is it the expected behavior ?
In fact, I thought Modules would try to unload « apps/fltExport/<any version> » when running « module switch apps/fltExport/v2.017 ».

What do you think ?

Best regards,
Laurent.

PS : I found an intermediate syntax that works :

module switch others/texlive others/texlive/2022
module switch apps/python    apps/python/3.9.6
module switch apps/fltExport apps/fltExport/v2.017
module switch others/nodejs  others/nodejs/16.17.1

[Modules] SC25

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

Dear All,

Modules is at #SC25 in St. Louis!
Come meet me:

📅 Tuesday, Nov. 18
📍 CEA booth #2724
⏰ 10:00 – 11:45 AM

📅 Wednesday, Nov. 19
📍 High Performance Software Foundation (HPSF) booth #6134
⏰ 2:00 – 4:00 PM

Stop by to hear the latest project updates, see demos of new features,
and pick up some stickers!

Best,
Xavier

Re: [Modules] Proposal to improve the way to load Python module function

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

Thanks a lot Byron for this pull request. It is preferable to move
further discussion on the pull request.

Best,
Xavier

Le ven. 14 nov. 2025 à 17:35, Byron Boulton via Modules-interest
<mod...@li...> a écrit :
>
> I created a draft pull request from my work so far with some notes on my status. Does this project prefer to move further discussion on this pull request or to continues feedback process here in the mailing list?
>
> Byron Boulton
>
> -------- Original Message --------
> On Tuesday, 11/11/25 at 13:33 Xavier Delaruelle <xav...@gm...> wrote:
> The Modules release zipball provided for Windows do not contain an
> initialization script for python currently. So there is no need to
> provide a "python.py" compatibility script for this platform.
>
> Best regards,
> Xavier
>
>
> Le lun. 10 nov. 2025 à 22:42, Paul Markfort <pau...@gm...> a écrit :
> >
> > Windows (since Windows 7) does support symlinks.
> > The command is mklink (I think it is a cmd.exe built-in).
> >
> > Unfortunately, only administrators can make links (unless you change the security policy in windows).
> > Also - links in windows have a lot of issues (one is the copy and robocopy commands don't really handle them correctly).
> > Sourcing one file from the other is probably the best way to handle this (on Windows and Linux).
> >
> > The module installation routine could determine if a python.py is there, and it should issue a warning if it is, then either install a default env_modules.py that sources python.py, or rename python.py
> >
> >
> >
> > On 2025-11-10 2:49 PM, Xavier Delaruelle wrote:
> > > For Windows, you may just duplicate the file instead of the symlink.
> > > python.py init script will only be removed when releasing a new major
> > > version (v6). There will be documentation indicating the breaking
> > > changes. I think that will be sufficient. And for people currently
> > > using "python.py", I think they will not be happy to see a warning
> > > message.
> > >
> > > Xavier
> > >
> > > Le lun. 10 nov. 2025 à 20:08, Byron Boulton via Modules-interest
> > > <mod...@li...> a écrit :
> > >>
> > >> I'll definitely have to read through that file and get a better understanding of what it's doing. The Python code I'm having to write is to deal with the backwards compatibility of having the python.py file.
> > >>
> > >> Since environment modules supports Windows, but Windows doesn't support symlinks by default. So instead of a symlink my python.py grabs all variables/functions defined by the newly-renamed env_modules.py file and warns the users that using python.py is deprecated.
> > >>
> > >> Byron Boulton
> > >>
> > >> On Monday, November 10th, 2025 at 1:45 PM, Xavier Delaruelle <xav...@gm...> wrote:
> > >>
> > >>> Not sure there is a need to write Python code. I would suggest to
> > >>> update the cmdModuleAutoinit procedure to append-path the initdir to
> > >>> PYTHONPATH if configuration option is enabled:
> > >>>
> > >>> https://github.com/envmodules/modules/blob/2c416a8ebc95ee54e6653dbb47294563ad41721c/tcl/subcmd.tcl.in#L2032
> > >>>
> > >>> This way PYTHONPATH is adjusted when Modules initializes on all shells
> > >>> or langs supported.
> > >>>
> > >>> Best,
> > >>> Xavier
> > >>>
> > >>> Le lun. 10 nov. 2025 à 14:40, Byron Boulton via Modules-interest
> > >>> mod...@li... a écrit :
> > >>>
> > >>>> Is there an oldest version of Python we're supporting? For example, Python 3.6 or later? Note that Python 2.7 went end of life January 2020 (almost 6 years ago) and Python 3.6 went end of life December 2021 (almost 4 years ago). It would love to be able to use Pathlib which came in Python 3.4 and f-strings which came in Python 3.6.
> > >>>>
> > >>>> Byron Boulton
> > >>>>
> > >>>> On Sunday, November 9th, 2025 at 1:17 PM, Xavier Delaruelle xav...@gm... wrote:
> > >>>>
> > >>>>> Hello Byron,
> > >>>>>
> > >>>>> Thanks for your message. This is linked to
> > >>>>> https://github.com/envmodules/modules/issues/483.
> > >>>>>
> > >>>>> I am ok with the pull request you propose. Please take into account
> > >>>>> the following points:
> > >>>>> * I would prefer the init script to be renamed env_modules.py
> > >>>>> * At installation time a python.py symlink should be created not to
> > >>>>> break existing script relying on this file name
> > >>>>> * add a new configuration option that if activated adds the init dir
> > >>>>> path to the PYTHONPATH env variable during autoinit process
> > >>>>>
> > >>>>> Best,
> > >>>>> Xavier
> > >>>>>
> > >>>>> Le ven. 7 nov. 2025 à 21:02, Byron Boulton via Modules-interest
> > >>>>> mod...@li... a écrit :
> > >>>>>
> > >>>>>> To make things clearer for this email I'll use "Python-module" to refer to a Python script defining functions/classes that you `import` in Python code and "environment-module" to refer to a TCL environment module that you `module load`/`module unload`/etc.
> > >>>>>>
> > >>>>>> I was looking at how to use environment-modules within a Python script and found that the current documentation for Python (https://modules.readthedocs.io/en/latest/module.html#examples-of-initialization) has
> > >>>>>>
> > >>>>>> `import os exec(open("/usr/share/Modules/init/python.py").read(), globals()) module("load", "modulefile", "modulefile", "...")`
> > >>>>>>
> > >>>>>> A more Pythonic approach would be to `import` this `module` function somehow. Currently, you can do that with as follows
> > >>>>>>
> > >>>>>> `import sys sys.path.append("/usr/share/Modules/init") from python import module module("load", "modulefile", "moduelfile", "...")`
> > >>>>>>
> > >>>>>> The issues with this are that you have to modify the `sys.path` inside the script and since the Python-module `import`-ed is called "python". The name makes it look like `module` is a function from some core Python-module from the Python project.
> > >>>>>>
> > >>>>>> I'm proposing to write a pull request to
> > >>>>>> 1. rename the Python initialization file to something like `env_module_python.py` (this is what lmod named theirs by the way) and
> > >>>>>> 2. to have the shell initialization scripts add the folder of initilization scripts to the PYTHONPATH environment variable. These changes would change Python initialization to
> > >>>>>>
> > >>>>>> `from env_module_python import module module("load", "modulefile", "moduelfile", "...")`
> > >>>>>>
> > >>>>>> which cleans up the way the Python script imports the `module` function and communicates more clearly that it comes from a 3rd-party Python-module related to environment modules.
> > >>>>>>
> > >>>>>> Byron Boulton
> > >>>>>>
> > >>>>>> _______________________________________________
> > >>>>>> Modules-interest mailing list
> > >>>>>> Mod...@li...
> > >>>>>> https://lists.sourceforge.net/lists/listinfo/modules-interest
> > >>>>>
> > >>>>> _______________________________________________
> > >>>>> Modules-interest mailing list
> > >>>>> Mod...@li...
> > >>>>> https://lists.sourceforge.net/lists/listinfo/modules-interest
> > >>>>
> > >>>> _______________________________________________
> > >>>> Modules-interest mailing list
> > >>>> Mod...@li...
> > >>>> https://lists.sourceforge.net/lists/listinfo/modules-interest
> > >>>
> > >>>
> > >>>
> > >>> _______________________________________________
> > >>> Modules-interest mailing list
> > >>> Mod...@li...
> > >>> https://lists.sourceforge.net/lists/listinfo/modules-interest
> > >>
> > >>
> > >> _______________________________________________
> > >> Modules-interest mailing list
> > >> Mod...@li...
> > >> https://lists.sourceforge.net/lists/listinfo/modules-interest
> > >
> > >
> > > _______________________________________________
> > > 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
>
>
> _______________________________________________
> 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] Proposal to improve the way to load Python module function

[Byron B. <byr...@pr...>]

I created a draft pull request from my work so far with some notes on my status. Does this project prefer to move further discussion on this pull request or to continues feedback process here in the mailing list?

Byron Boulton

-------- Original Message --------
On Tuesday, 11/11/25 at 13:33 Xavier Delaruelle <xav...@gm...> wrote:
The Modules release zipball provided for Windows do not contain an
initialization script for python currently. So there is no need to
provide a "python.py" compatibility script for this platform.

Best regards,
Xavier


Le lun. 10 nov. 2025 à 22:42, Paul Markfort <pau...@gm...> a écrit :
>
> Windows (since Windows 7) does support symlinks.
> The command is mklink (I think it is a cmd.exe built-in).
>
> Unfortunately, only administrators can make links (unless you change the security policy in windows).
> Also - links in windows have a lot of issues (one is the copy and robocopy commands don't really handle them correctly).
> Sourcing one file from the other is probably the best way to handle this (on Windows and Linux).
>
> The module installation routine could determine if a python.py is there, and it should issue a warning if it is, then either install a default env_modules.py that sources python.py, or rename python.py
>
>
>
> On 2025-11-10 2:49 PM, Xavier Delaruelle wrote:
> > For Windows, you may just duplicate the file instead of the symlink.
> > python.py init script will only be removed when releasing a new major
> > version (v6). There will be documentation indicating the breaking
> > changes. I think that will be sufficient. And for people currently
> > using "python.py", I think they will not be happy to see a warning
> > message.
> >
> > Xavier
> >
> > Le lun. 10 nov. 2025 à 20:08, Byron Boulton via Modules-interest
> > <mod...@li...> a écrit :
> >>
> >> I'll definitely have to read through that file and get a better understanding of what it's doing. The Python code I'm having to write is to deal with the backwards compatibility of having the python.py file.
> >>
> >> Since environment modules supports Windows, but Windows doesn't support symlinks by default. So instead of a symlink my python.py grabs all variables/functions defined by the newly-renamed env_modules.py file and warns the users that using python.py is deprecated.
> >>
> >> Byron Boulton
> >>
> >> On Monday, November 10th, 2025 at 1:45 PM, Xavier Delaruelle <xav...@gm...> wrote:
> >>
> >>> Not sure there is a need to write Python code. I would suggest to
> >>> update the cmdModuleAutoinit procedure to append-path the initdir to
> >>> PYTHONPATH if configuration option is enabled:
> >>>
> >>> https://github.com/envmodules/modules/blob/2c416a8ebc95ee54e6653dbb47294563ad41721c/tcl/subcmd.tcl.in#L2032
> >>>
> >>> This way PYTHONPATH is adjusted when Modules initializes on all shells
> >>> or langs supported.
> >>>
> >>> Best,
> >>> Xavier
> >>>
> >>> Le lun. 10 nov. 2025 à 14:40, Byron Boulton via Modules-interest
> >>> mod...@li... a écrit :
> >>>
> >>>> Is there an oldest version of Python we're supporting? For example, Python 3.6 or later? Note that Python 2.7 went end of life January 2020 (almost 6 years ago) and Python 3.6 went end of life December 2021 (almost 4 years ago). It would love to be able to use Pathlib which came in Python 3.4 and f-strings which came in Python 3.6.
> >>>>
> >>>> Byron Boulton
> >>>>
> >>>> On Sunday, November 9th, 2025 at 1:17 PM, Xavier Delaruelle xav...@gm... wrote:
> >>>>
> >>>>> Hello Byron,
> >>>>>
> >>>>> Thanks for your message. This is linked to
> >>>>> https://github.com/envmodules/modules/issues/483.
> >>>>>
> >>>>> I am ok with the pull request you propose. Please take into account
> >>>>> the following points:
> >>>>> * I would prefer the init script to be renamed env_modules.py
> >>>>> * At installation time a python.py symlink should be created not to
> >>>>> break existing script relying on this file name
> >>>>> * add a new configuration option that if activated adds the init dir
> >>>>> path to the PYTHONPATH env variable during autoinit process
> >>>>>
> >>>>> Best,
> >>>>> Xavier
> >>>>>
> >>>>> Le ven. 7 nov. 2025 à 21:02, Byron Boulton via Modules-interest
> >>>>> mod...@li... a écrit :
> >>>>>
> >>>>>> To make things clearer for this email I'll use "Python-module" to refer to a Python script defining functions/classes that you `import` in Python code and "environment-module" to refer to a TCL environment module that you `module load`/`module unload`/etc.
> >>>>>>
> >>>>>> I was looking at how to use environment-modules within a Python script and found that the current documentation for Python (https://modules.readthedocs.io/en/latest/module.html#examples-of-initialization) has
> >>>>>>
> >>>>>> `import os exec(open("/usr/share/Modules/init/python.py").read(), globals()) module("load", "modulefile", "modulefile", "...")`
> >>>>>>
> >>>>>> A more Pythonic approach would be to `import` this `module` function somehow. Currently, you can do that with as follows
> >>>>>>
> >>>>>> `import sys sys.path.append("/usr/share/Modules/init") from python import module module("load", "modulefile", "moduelfile", "...")`
> >>>>>>
> >>>>>> The issues with this are that you have to modify the `sys.path` inside the script and since the Python-module `import`-ed is called "python". The name makes it look like `module` is a function from some core Python-module from the Python project.
> >>>>>>
> >>>>>> I'm proposing to write a pull request to
> >>>>>> 1. rename the Python initialization file to something like `env_module_python.py` (this is what lmod named theirs by the way) and
> >>>>>> 2. to have the shell initialization scripts add the folder of initilization scripts to the PYTHONPATH environment variable. These changes would change Python initialization to
> >>>>>>
> >>>>>> `from env_module_python import module module("load", "modulefile", "moduelfile", "...")`
> >>>>>>
> >>>>>> which cleans up the way the Python script imports the `module` function and communicates more clearly that it comes from a 3rd-party Python-module related to environment modules.
> >>>>>>
> >>>>>> Byron Boulton
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> Modules-interest mailing list
> >>>>>> Mod...@li...
> >>>>>> https://lists.sourceforge.net/lists/listinfo/modules-interest
> >>>>>
> >>>>> _______________________________________________
> >>>>> Modules-interest mailing list
> >>>>> Mod...@li...
> >>>>> https://lists.sourceforge.net/lists/listinfo/modules-interest
> >>>>
> >>>> _______________________________________________
> >>>> Modules-interest mailing list
> >>>> Mod...@li...
> >>>> https://lists.sourceforge.net/lists/listinfo/modules-interest
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Modules-interest mailing list
> >>> Mod...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/modules-interest
> >>
> >>
> >> _______________________________________________
> >> Modules-interest mailing list
> >> Mod...@li...
> >> https://lists.sourceforge.net/lists/listinfo/modules-interest
> >
> >
> > _______________________________________________
> > 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


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

Re: [Modules] Proposal to improve the way to load Python module function

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

The Modules release zipball provided for Windows do not contain an
initialization script for python currently. So there is no need to
provide a "python.py" compatibility script for this platform.

Best regards,
Xavier


Le lun. 10 nov. 2025 à 22:42, Paul Markfort <pau...@gm...> a écrit :
>
> Windows (since Windows 7) does support symlinks.
> The command is mklink (I think it is a cmd.exe built-in).
>
> Unfortunately, only administrators can make links (unless you change the security policy in windows).
> Also - links in windows have a lot of issues (one is the copy and robocopy commands don't really handle them correctly).
> Sourcing one file from the other is probably the best way to handle this (on Windows and Linux).
>
> The module installation routine could determine if a python.py is there, and it should issue a warning if it is, then either install a default env_modules.py that sources python.py, or rename python.py
>
>
>
> On 2025-11-10 2:49 PM, Xavier Delaruelle wrote:
> > For Windows, you may just duplicate the file instead of the symlink.
> > python.py init script will only be removed when releasing a new major
> > version (v6). There will be documentation indicating the breaking
> > changes. I think that will be sufficient. And for people currently
> > using "python.py", I think they will not be happy to see a warning
> > message.
> >
> > Xavier
> >
> > Le lun. 10 nov. 2025 à 20:08, Byron Boulton via Modules-interest
> > <mod...@li...> a écrit :
> >>
> >> I'll definitely have to read through that file and get a better understanding of what it's doing. The Python code I'm having to write is to deal with the backwards compatibility of having the python.py file.
> >>
> >> Since environment modules supports Windows, but Windows doesn't support symlinks by default. So instead of a symlink my python.py grabs all variables/functions defined by the newly-renamed env_modules.py file and warns the users that using python.py is deprecated.
> >>
> >> Byron Boulton
> >>
> >> On Monday, November 10th, 2025 at 1:45 PM, Xavier Delaruelle <xav...@gm...> wrote:
> >>
> >>> Not sure there is a need to write Python code. I would suggest to
> >>> update the cmdModuleAutoinit procedure to append-path the initdir to
> >>> PYTHONPATH if configuration option is enabled:
> >>>
> >>> https://github.com/envmodules/modules/blob/2c416a8ebc95ee54e6653dbb47294563ad41721c/tcl/subcmd.tcl.in#L2032
> >>>
> >>> This way PYTHONPATH is adjusted when Modules initializes on all shells
> >>> or langs supported.
> >>>
> >>> Best,
> >>> Xavier
> >>>
> >>> Le lun. 10 nov. 2025 à 14:40, Byron Boulton via Modules-interest
> >>> mod...@li... a écrit :
> >>>
> >>>> Is there an oldest version of Python we're supporting? For example, Python 3.6 or later? Note that Python 2.7 went end of life January 2020 (almost 6 years ago) and Python 3.6 went end of life December 2021 (almost 4 years ago). It would love to be able to use Pathlib which came in Python 3.4 and f-strings which came in Python 3.6.
> >>>>
> >>>> Byron Boulton
> >>>>
> >>>> On Sunday, November 9th, 2025 at 1:17 PM, Xavier Delaruelle xav...@gm... wrote:
> >>>>
> >>>>> Hello Byron,
> >>>>>
> >>>>> Thanks for your message. This is linked to
> >>>>> https://github.com/envmodules/modules/issues/483.
> >>>>>
> >>>>> I am ok with the pull request you propose. Please take into account
> >>>>> the following points:
> >>>>> * I would prefer the init script to be renamed env_modules.py
> >>>>> * At installation time a python.py symlink should be created not to
> >>>>> break existing script relying on this file name
> >>>>> * add a new configuration option that if activated adds the init dir
> >>>>> path to the PYTHONPATH env variable during autoinit process
> >>>>>
> >>>>> Best,
> >>>>> Xavier
> >>>>>
> >>>>> Le ven. 7 nov. 2025 à 21:02, Byron Boulton via Modules-interest
> >>>>> mod...@li... a écrit :
> >>>>>
> >>>>>> To make things clearer for this email I'll use "Python-module" to refer to a Python script defining functions/classes that you `import` in Python code and "environment-module" to refer to a TCL environment module that you `module load`/`module unload`/etc.
> >>>>>>
> >>>>>> I was looking at how to use environment-modules within a Python script and found that the current documentation for Python (https://modules.readthedocs.io/en/latest/module.html#examples-of-initialization) has
> >>>>>>
> >>>>>> `import os exec(open("/usr/share/Modules/init/python.py").read(), globals()) module("load", "modulefile", "modulefile", "...")`
> >>>>>>
> >>>>>> A more Pythonic approach would be to `import` this `module` function somehow. Currently, you can do that with as follows
> >>>>>>
> >>>>>> `import sys sys.path.append("/usr/share/Modules/init") from python import module module("load", "modulefile", "moduelfile", "...")`
> >>>>>>
> >>>>>> The issues with this are that you have to modify the `sys.path` inside the script and since the Python-module `import`-ed is called "python". The name makes it look like `module` is a function from some core Python-module from the Python project.
> >>>>>>
> >>>>>> I'm proposing to write a pull request to
> >>>>>> 1. rename the Python initialization file to something like `env_module_python.py` (this is what lmod named theirs by the way) and
> >>>>>> 2. to have the shell initialization scripts add the folder of initilization scripts to the PYTHONPATH environment variable. These changes would change Python initialization to
> >>>>>>
> >>>>>> `from env_module_python import module module("load", "modulefile", "moduelfile", "...")`
> >>>>>>
> >>>>>> which cleans up the way the Python script imports the `module` function and communicates more clearly that it comes from a 3rd-party Python-module related to environment modules.
> >>>>>>
> >>>>>> Byron Boulton
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> Modules-interest mailing list
> >>>>>> Mod...@li...
> >>>>>> https://lists.sourceforge.net/lists/listinfo/modules-interest
> >>>>>
> >>>>> _______________________________________________
> >>>>> Modules-interest mailing list
> >>>>> Mod...@li...
> >>>>> https://lists.sourceforge.net/lists/listinfo/modules-interest
> >>>>
> >>>> _______________________________________________
> >>>> Modules-interest mailing list
> >>>> Mod...@li...
> >>>> https://lists.sourceforge.net/lists/listinfo/modules-interest
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Modules-interest mailing list
> >>> Mod...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/modules-interest
> >>
> >>
> >> _______________________________________________
> >> Modules-interest mailing list
> >> Mod...@li...
> >> https://lists.sourceforge.net/lists/listinfo/modules-interest
> >
> >
> > _______________________________________________
> > 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] Proposal to improve the way to load Python module function

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

Windows (since Windows 7) does support symlinks.
The command is mklink (I think it is a cmd.exe built-in).

Unfortunately, only administrators can make links (unless you change the security policy in windows).
Also - links in windows have a lot of issues (one is the copy and robocopy commands don't really handle them correctly).
Sourcing one file from the other is probably the best way to handle this (on Windows and Linux).

The module installation routine could determine if a python.py is there, and it should issue a warning if it is, then either install a default env_modules.py that sources python.py, or rename python.py



On 2025-11-10 2:49 PM, Xavier Delaruelle wrote:
> For Windows, you may just duplicate the file instead of the symlink.
> python.py init script will only be removed when releasing a new major
> version (v6). There will be documentation indicating the breaking
> changes. I think that will be sufficient. And for people currently
> using "python.py", I think they will not be happy to see a warning
> message.
> 
> Xavier
> 
> Le lun. 10 nov. 2025 à 20:08, Byron Boulton via Modules-interest
> <mod...@li...> a écrit :
>>
>> I'll definitely have to read through that file and get a better understanding of what it's doing. The Python code I'm having to write is to deal with the backwards compatibility of having the python.py file.
>>
>> Since environment modules supports Windows, but Windows doesn't support symlinks by default. So instead of a symlink my python.py grabs all variables/functions defined by the newly-renamed env_modules.py file and warns the users that using python.py is deprecated.
>>
>> Byron Boulton
>>
>> On Monday, November 10th, 2025 at 1:45 PM, Xavier Delaruelle <xav...@gm...> wrote:
>>
>>> Not sure there is a need to write Python code. I would suggest to
>>> update the cmdModuleAutoinit procedure to append-path the initdir to
>>> PYTHONPATH if configuration option is enabled:
>>>
>>> https://github.com/envmodules/modules/blob/2c416a8ebc95ee54e6653dbb47294563ad41721c/tcl/subcmd.tcl.in#L2032
>>>
>>> This way PYTHONPATH is adjusted when Modules initializes on all shells
>>> or langs supported.
>>>
>>> Best,
>>> Xavier
>>>
>>> Le lun. 10 nov. 2025 à 14:40, Byron Boulton via Modules-interest
>>> mod...@li... a écrit :
>>>
>>>> Is there an oldest version of Python we're supporting? For example, Python 3.6 or later? Note that Python 2.7 went end of life January 2020 (almost 6 years ago) and Python 3.6 went end of life December 2021 (almost 4 years ago). It would love to be able to use Pathlib which came in Python 3.4 and f-strings which came in Python 3.6.
>>>>
>>>> Byron Boulton
>>>>
>>>> On Sunday, November 9th, 2025 at 1:17 PM, Xavier Delaruelle xav...@gm... wrote:
>>>>
>>>>> Hello Byron,
>>>>>
>>>>> Thanks for your message. This is linked to
>>>>> https://github.com/envmodules/modules/issues/483.
>>>>>
>>>>> I am ok with the pull request you propose. Please take into account
>>>>> the following points:
>>>>> * I would prefer the init script to be renamed env_modules.py
>>>>> * At installation time a python.py symlink should be created not to
>>>>> break existing script relying on this file name
>>>>> * add a new configuration option that if activated adds the init dir
>>>>> path to the PYTHONPATH env variable during autoinit process
>>>>>
>>>>> Best,
>>>>> Xavier
>>>>>
>>>>> Le ven. 7 nov. 2025 à 21:02, Byron Boulton via Modules-interest
>>>>> mod...@li... a écrit :
>>>>>
>>>>>> To make things clearer for this email I'll use "Python-module" to refer to a Python script defining functions/classes that you `import` in Python code and "environment-module" to refer to a TCL environment module that you `module load`/`module unload`/etc.
>>>>>>
>>>>>> I was looking at how to use environment-modules within a Python script and found that the current documentation for Python (https://modules.readthedocs.io/en/latest/module.html#examples-of-initialization) has
>>>>>>
>>>>>> `import os exec(open("/usr/share/Modules/init/python.py").read(), globals()) module("load", "modulefile", "modulefile", "...")`
>>>>>>
>>>>>> A more Pythonic approach would be to `import` this `module` function somehow. Currently, you can do that with as follows
>>>>>>
>>>>>> `import sys sys.path.append("/usr/share/Modules/init") from python import module module("load", "modulefile", "moduelfile", "...")`
>>>>>>
>>>>>> The issues with this are that you have to modify the `sys.path` inside the script and since the Python-module `import`-ed is called "python". The name makes it look like `module` is a function from some core Python-module from the Python project.
>>>>>>
>>>>>> I'm proposing to write a pull request to
>>>>>> 1. rename the Python initialization file to something like `env_module_python.py` (this is what lmod named theirs by the way) and
>>>>>> 2. to have the shell initialization scripts add the folder of initilization scripts to the PYTHONPATH environment variable. These changes would change Python initialization to
>>>>>>
>>>>>> `from env_module_python import module module("load", "modulefile", "moduelfile", "...")`
>>>>>>
>>>>>> which cleans up the way the Python script imports the `module` function and communicates more clearly that it comes from a 3rd-party Python-module related to environment modules.
>>>>>>
>>>>>> Byron Boulton
>>>>>>
>>>>>> _______________________________________________
>>>>>> Modules-interest mailing list
>>>>>> Mod...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/modules-interest
>>>>>
>>>>> _______________________________________________
>>>>> Modules-interest mailing list
>>>>> Mod...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/modules-interest
>>>>
>>>> _______________________________________________
>>>> Modules-interest mailing list
>>>> Mod...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/modules-interest
>>>
>>>
>>>
>>> _______________________________________________
>>> Modules-interest mailing list
>>> Mod...@li...
>>> https://lists.sourceforge.net/lists/listinfo/modules-interest
>>
>>
>> _______________________________________________
>> Modules-interest mailing list
>> Mod...@li...
>> https://lists.sourceforge.net/lists/listinfo/modules-interest
> 
> 
> _______________________________________________
> 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] Proposal to improve the way to load Python module function

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

For Windows, you may just duplicate the file instead of the symlink.
python.py init script will only be removed when releasing a new major
version (v6). There will be documentation indicating the breaking
changes. I think that will be sufficient. And for people currently
using "python.py", I think they will not be happy to see a warning
message.

Xavier

Le lun. 10 nov. 2025 à 20:08, Byron Boulton via Modules-interest
<mod...@li...> a écrit :
>
> I'll definitely have to read through that file and get a better understanding of what it's doing. The Python code I'm having to write is to deal with the backwards compatibility of having the python.py file.
>
> Since environment modules supports Windows, but Windows doesn't support symlinks by default. So instead of a symlink my python.py grabs all variables/functions defined by the newly-renamed env_modules.py file and warns the users that using python.py is deprecated.
>
> Byron Boulton
>
> On Monday, November 10th, 2025 at 1:45 PM, Xavier Delaruelle <xav...@gm...> wrote:
>
> > Not sure there is a need to write Python code. I would suggest to
> > update the cmdModuleAutoinit procedure to append-path the initdir to
> > PYTHONPATH if configuration option is enabled:
> >
> > https://github.com/envmodules/modules/blob/2c416a8ebc95ee54e6653dbb47294563ad41721c/tcl/subcmd.tcl.in#L2032
> >
> > This way PYTHONPATH is adjusted when Modules initializes on all shells
> > or langs supported.
> >
> > Best,
> > Xavier
> >
> > Le lun. 10 nov. 2025 à 14:40, Byron Boulton via Modules-interest
> > mod...@li... a écrit :
> >
> > > Is there an oldest version of Python we're supporting? For example, Python 3.6 or later? Note that Python 2.7 went end of life January 2020 (almost 6 years ago) and Python 3.6 went end of life December 2021 (almost 4 years ago). It would love to be able to use Pathlib which came in Python 3.4 and f-strings which came in Python 3.6.
> > >
> > > Byron Boulton
> > >
> > > On Sunday, November 9th, 2025 at 1:17 PM, Xavier Delaruelle xav...@gm... wrote:
> > >
> > > > Hello Byron,
> > > >
> > > > Thanks for your message. This is linked to
> > > > https://github.com/envmodules/modules/issues/483.
> > > >
> > > > I am ok with the pull request you propose. Please take into account
> > > > the following points:
> > > > * I would prefer the init script to be renamed env_modules.py
> > > > * At installation time a python.py symlink should be created not to
> > > > break existing script relying on this file name
> > > > * add a new configuration option that if activated adds the init dir
> > > > path to the PYTHONPATH env variable during autoinit process
> > > >
> > > > Best,
> > > > Xavier
> > > >
> > > > Le ven. 7 nov. 2025 à 21:02, Byron Boulton via Modules-interest
> > > > mod...@li... a écrit :
> > > >
> > > > > To make things clearer for this email I'll use "Python-module" to refer to a Python script defining functions/classes that you `import` in Python code and "environment-module" to refer to a TCL environment module that you `module load`/`module unload`/etc.
> > > > >
> > > > > I was looking at how to use environment-modules within a Python script and found that the current documentation for Python (https://modules.readthedocs.io/en/latest/module.html#examples-of-initialization) has
> > > > >
> > > > > `import os exec(open("/usr/share/Modules/init/python.py").read(), globals()) module("load", "modulefile", "modulefile", "...")`
> > > > >
> > > > > A more Pythonic approach would be to `import` this `module` function somehow. Currently, you can do that with as follows
> > > > >
> > > > > `import sys sys.path.append("/usr/share/Modules/init") from python import module module("load", "modulefile", "moduelfile", "...")`
> > > > >
> > > > > The issues with this are that you have to modify the `sys.path` inside the script and since the Python-module `import`-ed is called "python". The name makes it look like `module` is a function from some core Python-module from the Python project.
> > > > >
> > > > > I'm proposing to write a pull request to
> > > > > 1. rename the Python initialization file to something like `env_module_python.py` (this is what lmod named theirs by the way) and
> > > > > 2. to have the shell initialization scripts add the folder of initilization scripts to the PYTHONPATH environment variable. These changes would change Python initialization to
> > > > >
> > > > > `from env_module_python import module module("load", "modulefile", "moduelfile", "...")`
> > > > >
> > > > > which cleans up the way the Python script imports the `module` function and communicates more clearly that it comes from a 3rd-party Python-module related to environment modules.
> > > > >
> > > > > Byron Boulton
> > > > >
> > > > > _______________________________________________
> > > > > Modules-interest mailing list
> > > > > Mod...@li...
> > > > > https://lists.sourceforge.net/lists/listinfo/modules-interest
> > > >
> > > > _______________________________________________
> > > > Modules-interest mailing list
> > > > Mod...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/modules-interest
> > >
> > > _______________________________________________
> > > Modules-interest mailing list
> > > Mod...@li...
> > > https://lists.sourceforge.net/lists/listinfo/modules-interest
> >
> >
> >
> > _______________________________________________
> > Modules-interest mailing list
> > Mod...@li...
> > https://lists.sourceforge.net/lists/listinfo/modules-interest
>
>
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest

Re: [Modules] Modules joins HPSF

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

Wow, this is a huge achievement!
Congratulations.

Roberto
On 10 Nov 2025 at 19:21 +0100, Xavier Delaruelle <xav...@gm...>, wrote:
> Dear All,
>
> I am glad to announce that we are officially part of the High
> Performance Software Foundation.
>
> Modules has been integrated as an established project.
>
> See full announcement post:
> https://hpsf.io/blog/2025/high-performance-software-foundation-welcomes-modules-as-hpsf-project/
>
> Best regards,
> Xavier
>
>
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest

Re: [Modules] Proposal to improve the way to load Python module function

[Byron B. <byr...@pr...>]

I'll definitely have to read through that file and get a better understanding of what it's doing. The Python code I'm having to write is to deal with the backwards compatibility of having the python.py file.

Since environment modules supports Windows, but Windows doesn't support symlinks by default. So instead of a symlink my python.py grabs all variables/functions defined by the newly-renamed env_modules.py file and warns the users that using python.py is deprecated.

Byron Boulton

On Monday, November 10th, 2025 at 1:45 PM, Xavier Delaruelle <xav...@gm...> wrote:

> Not sure there is a need to write Python code. I would suggest to
> update the cmdModuleAutoinit procedure to append-path the initdir to
> PYTHONPATH if configuration option is enabled:
> 
> https://github.com/envmodules/modules/blob/2c416a8ebc95ee54e6653dbb47294563ad41721c/tcl/subcmd.tcl.in#L2032
> 
> This way PYTHONPATH is adjusted when Modules initializes on all shells
> or langs supported.
> 
> Best,
> Xavier
> 
> Le lun. 10 nov. 2025 à 14:40, Byron Boulton via Modules-interest
> mod...@li... a écrit :
> 
> > Is there an oldest version of Python we're supporting? For example, Python 3.6 or later? Note that Python 2.7 went end of life January 2020 (almost 6 years ago) and Python 3.6 went end of life December 2021 (almost 4 years ago). It would love to be able to use Pathlib which came in Python 3.4 and f-strings which came in Python 3.6.
> > 
> > Byron Boulton
> > 
> > On Sunday, November 9th, 2025 at 1:17 PM, Xavier Delaruelle xav...@gm... wrote:
> > 
> > > Hello Byron,
> > > 
> > > Thanks for your message. This is linked to
> > > https://github.com/envmodules/modules/issues/483.
> > > 
> > > I am ok with the pull request you propose. Please take into account
> > > the following points:
> > > * I would prefer the init script to be renamed env_modules.py
> > > * At installation time a python.py symlink should be created not to
> > > break existing script relying on this file name
> > > * add a new configuration option that if activated adds the init dir
> > > path to the PYTHONPATH env variable during autoinit process
> > > 
> > > Best,
> > > Xavier
> > > 
> > > Le ven. 7 nov. 2025 à 21:02, Byron Boulton via Modules-interest
> > > mod...@li... a écrit :
> > > 
> > > > To make things clearer for this email I'll use "Python-module" to refer to a Python script defining functions/classes that you `import` in Python code and "environment-module" to refer to a TCL environment module that you `module load`/`module unload`/etc.
> > > > 
> > > > I was looking at how to use environment-modules within a Python script and found that the current documentation for Python (https://modules.readthedocs.io/en/latest/module.html#examples-of-initialization) has
> > > > 
> > > > `import os exec(open("/usr/share/Modules/init/python.py").read(), globals()) module("load", "modulefile", "modulefile", "...")`
> > > > 
> > > > A more Pythonic approach would be to `import` this `module` function somehow. Currently, you can do that with as follows
> > > > 
> > > > `import sys sys.path.append("/usr/share/Modules/init") from python import module module("load", "modulefile", "moduelfile", "...")`
> > > > 
> > > > The issues with this are that you have to modify the `sys.path` inside the script and since the Python-module `import`-ed is called "python". The name makes it look like `module` is a function from some core Python-module from the Python project.
> > > > 
> > > > I'm proposing to write a pull request to
> > > > 1. rename the Python initialization file to something like `env_module_python.py` (this is what lmod named theirs by the way) and
> > > > 2. to have the shell initialization scripts add the folder of initilization scripts to the PYTHONPATH environment variable. These changes would change Python initialization to
> > > > 
> > > > `from env_module_python import module module("load", "modulefile", "moduelfile", "...")`
> > > > 
> > > > which cleans up the way the Python script imports the `module` function and communicates more clearly that it comes from a 3rd-party Python-module related to environment modules.
> > > > 
> > > > Byron Boulton
> > > > 
> > > > _______________________________________________
> > > > 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] Proposal to improve the way to load Python module function

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

Not sure there is a need to write Python code. I would suggest to
update the cmdModuleAutoinit procedure to append-path the initdir to
PYTHONPATH if configuration option is enabled:

https://github.com/envmodules/modules/blob/2c416a8ebc95ee54e6653dbb47294563ad41721c/tcl/subcmd.tcl.in#L2032

This way PYTHONPATH is adjusted when Modules initializes on all shells
or langs supported.

Best,
Xavier

Le lun. 10 nov. 2025 à 14:40, Byron Boulton via Modules-interest
<mod...@li...> a écrit :
>
> Is there an oldest version of Python we're supporting? For example, Python 3.6 or later? Note that Python 2.7 went end of life January 2020 (almost 6 years ago) and Python 3.6 went end of life December 2021 (almost 4 years ago). It would love to be able to use Pathlib which came in Python 3.4 and f-strings which came in Python 3.6.
>
> Byron Boulton
>
> On Sunday, November 9th, 2025 at 1:17 PM, Xavier Delaruelle <xav...@gm...> wrote:
>
> > Hello Byron,
> >
> > Thanks for your message. This is linked to
> > https://github.com/envmodules/modules/issues/483.
> >
> > I am ok with the pull request you propose. Please take into account
> > the following points:
> > * I would prefer the init script to be renamed env_modules.py
> > * At installation time a python.py symlink should be created not to
> > break existing script relying on this file name
> > * add a new configuration option that if activated adds the init dir
> > path to the PYTHONPATH env variable during autoinit process
> >
> > Best,
> > Xavier
> >
> >
> >
> >
> > Le ven. 7 nov. 2025 à 21:02, Byron Boulton via Modules-interest
> > mod...@li... a écrit :
> >
> > > To make things clearer for this email I'll use "Python-module" to refer to a Python script defining functions/classes that you `import` in Python code and "environment-module" to refer to a TCL environment module that you `module load`/`module unload`/etc.
> > >
> > > I was looking at how to use environment-modules within a Python script and found that the current documentation for Python (https://modules.readthedocs.io/en/latest/module.html#examples-of-initialization) has
> > >
> > > `import os exec(open("/usr/share/Modules/init/python.py").read(), globals()) module("load", "modulefile", "modulefile", "...")`
> > >
> > > A more Pythonic approach would be to `import` this `module` function somehow. Currently, you can do that with as follows
> > >
> > > `import sys sys.path.append("/usr/share/Modules/init") from python import module module("load", "modulefile", "moduelfile", "...")`
> > >
> > > The issues with this are that you have to modify the `sys.path` inside the script and since the Python-module `import`-ed is called "python". The name makes it look like `module` is a function from some core Python-module from the Python project.
> > >
> > > I'm proposing to write a pull request to
> > > 1. rename the Python initialization file to something like `env_module_python.py` (this is what lmod named theirs by the way) and
> > > 2. to have the shell initialization scripts add the folder of initilization scripts to the PYTHONPATH environment variable. These changes would change Python initialization to
> > >
> > > `from env_module_python import module module("load", "modulefile", "moduelfile", "...")`
> > >
> > > which cleans up the way the Python script imports the `module` function and communicates more clearly that it comes from a 3rd-party Python-module related to environment modules.
> > >
> > > Byron Boulton
> > >
> > > _______________________________________________
> > > 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] Modules joins HPSF

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

Dear All,

I am glad to announce that we are officially part of the High
Performance Software Foundation.

Modules has been integrated as an established project.

See full announcement post:
https://hpsf.io/blog/2025/high-performance-software-foundation-welcomes-modules-as-hpsf-project/

Best regards,
Xavier

Re: [Modules] Proposal to improve the way to load Python module function

[Byron B. <byr...@pr...>]

Is there an oldest version of Python we're supporting? For example, Python 3.6 or later? Note that Python 2.7 went end of life January 2020 (almost 6 years ago) and Python 3.6 went end of life December 2021 (almost 4 years ago). It would love to be able to use Pathlib which came in Python 3.4 and f-strings which came in Python 3.6.

Byron Boulton

On Sunday, November 9th, 2025 at 1:17 PM, Xavier Delaruelle <xav...@gm...> wrote:

> Hello Byron,
> 
> Thanks for your message. This is linked to
> https://github.com/envmodules/modules/issues/483.
> 
> I am ok with the pull request you propose. Please take into account
> the following points:
> * I would prefer the init script to be renamed env_modules.py
> * At installation time a python.py symlink should be created not to
> break existing script relying on this file name
> * add a new configuration option that if activated adds the init dir
> path to the PYTHONPATH env variable during autoinit process
> 
> Best,
> Xavier
> 
> 
> 
> 
> Le ven. 7 nov. 2025 à 21:02, Byron Boulton via Modules-interest
> mod...@li... a écrit :
> 
> > To make things clearer for this email I'll use "Python-module" to refer to a Python script defining functions/classes that you `import` in Python code and "environment-module" to refer to a TCL environment module that you `module load`/`module unload`/etc.
> > 
> > I was looking at how to use environment-modules within a Python script and found that the current documentation for Python (https://modules.readthedocs.io/en/latest/module.html#examples-of-initialization) has
> > 
> > `import os exec(open("/usr/share/Modules/init/python.py").read(), globals()) module("load", "modulefile", "modulefile", "...")`
> > 
> > A more Pythonic approach would be to `import` this `module` function somehow. Currently, you can do that with as follows
> > 
> > `import sys sys.path.append("/usr/share/Modules/init") from python import module module("load", "modulefile", "moduelfile", "...")`
> > 
> > The issues with this are that you have to modify the `sys.path` inside the script and since the Python-module `import`-ed is called "python". The name makes it look like `module` is a function from some core Python-module from the Python project.
> > 
> > I'm proposing to write a pull request to
> > 1. rename the Python initialization file to something like `env_module_python.py` (this is what lmod named theirs by the way) and
> > 2. to have the shell initialization scripts add the folder of initilization scripts to the PYTHONPATH environment variable. These changes would change Python initialization to
> > 
> > `from env_module_python import module module("load", "modulefile", "moduelfile", "...")`
> > 
> > which cleans up the way the Python script imports the `module` function and communicates more clearly that it comes from a 3rd-party Python-module related to environment modules.
> > 
> > Byron Boulton
> > 
> > _______________________________________________
> > 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] Proposal to improve the way to load Python module function

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

Hello Byron,

Thanks for your message. This is linked to
https://github.com/envmodules/modules/issues/483.

I am ok with the pull request you propose. Please take into account
the following points:
* I would prefer the init script to be renamed env_modules.py
* At installation time a python.py symlink should be created not to
break existing script relying on this file name
* add a new configuration option that if activated adds the init dir
path to the PYTHONPATH env variable during autoinit process

Best,
Xavier




Le ven. 7 nov. 2025 à 21:02, Byron Boulton via Modules-interest
<mod...@li...> a écrit :
>
> To make things clearer for this email I'll use "Python-module" to refer to a Python script defining functions/classes  that you `import` in Python code and "environment-module" to refer to a TCL environment module that you `module load`/`module unload`/etc.
>
> I was looking at how to use environment-modules within a Python script and found that the current documentation for Python (https://modules.readthedocs.io/en/latest/module.html#examples-of-initialization) has
>
> ```
> import os
> exec(open("/usr/share/Modules/init/python.py").read(), globals())
> module("load", "modulefile", "modulefile", "...")
> ```
>
> A more Pythonic approach would be to `import` this `module` function somehow. Currently, you _can_ do that with as follows
>
> ```
> import sys
> sys.path.append("/usr/share/Modules/init")
> from python import module
> module("load", "modulefile", "moduelfile", "...")
> ```
>
> The issues with this are that you have to modify the `sys.path` inside the script and since the Python-module `import`-ed is called "python". The name makes it look like `module` is a function from some core Python-module from the Python project.
>
> I'm proposing to write a pull request to
> 1. rename the Python initialization file to something like `env_module_python.py` (this is what lmod named theirs by the way) and
> 2. to have the shell initialization scripts add the folder of initilization scripts to the PYTHONPATH environment variable. These changes would change Python initialization to
>
> ```
> from env_module_python import module
> module("load", "modulefile", "moduelfile", "...")
> ```
>
> which cleans up the way the Python script imports the `module` function and communicates more clearly that it comes from a 3rd-party Python-module related to environment modules.
>
> Byron Boulton
>
>
>
>
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest

[Modules] Proposal to improve the way to load Python module function

[Byron B. <byr...@pr...>]

To make things clearer for this email I'll use "Python-module" to refer to a Python script defining functions/classes  that you `import` in Python code and "environment-module" to refer to a TCL environment module that you `module load`/`module unload`/etc.

I was looking at how to use environment-modules within a Python script and found that the current documentation for Python (https://modules.readthedocs.io/en/latest/module.html#examples-of-initialization) has 

```
import os
exec(open("/usr/share/Modules/init/python.py").read(), globals())
module("load", "modulefile", "modulefile", "...")
```

A more Pythonic approach would be to `import` this `module` function somehow. Currently, you _can_ do that with as follows

```
import sys
sys.path.append("/usr/share/Modules/init")
from python import module
module("load", "modulefile", "moduelfile", "...")
```

The issues with this are that you have to modify the `sys.path` inside the script and since the Python-module `import`-ed is called "python". The name makes it look like `module` is a function from some core Python-module from the Python project.

I'm proposing to write a pull request to
1. rename the Python initialization file to something like `env_module_python.py` (this is what lmod named theirs by the way) and
2. to have the shell initialization scripts add the folder of initilization scripts to the PYTHONPATH environment variable. These changes would change Python initialization to

```
from env_module_python import module
module("load", "modulefile", "moduelfile", "...")
```

which cleans up the way the Python script imports the `module` function and communicates more clearly that it comes from a 3rd-party Python-module related to environment modules.

Byron Boulton

Re: [Modules] Problems with hierarchical modules

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

Dear Achim,

I am ok to proceed as you suggest.

I will incorporate these first comment in the wiki document.

Best,
Xavier

Le jeu. 6 nov. 2025 à 10:59, Gsell, Achim <ach...@ps...> a écrit :
>
> Dear Xavier,
>
> thanks a lot for your thoughts/comments!
>
> > On 1 Nov 2025, at 18:37, Xavier Delaruelle <xav...@gm...> wrote:
> >
> > To complete my previous email to give my view on how to proceed.
> >
> > I think we need to keep exchanging to refine things and build the list
> > of features that are currently missing in Modules and need to be
> > developed.
>
> I completely agree. We can use the document as basis and refine things there. Would this be ok for you? Or do you have another idea/proposal?
>
> I added you as collaborator to the Pmodules repository - so you can already edit the document.
>
> Thanks and best,
>
> Achim
>
> >
> > Best,
> > Xavier
> >
> > Le sam. 1 nov. 2025 à 18:21, Xavier Delaruelle
> > <xav...@gm...> a écrit :
> >>
> >> Dear Achim,
> >>
> >> Many thanks for this insighful document. I have made an initial
> >> analysis and below are my first thoughts.
> >>
> >> # Module configuration files
> >>
> >> As you point there is a strong preference in Modules to have the least
> >> possible files to read and even to test for existence. All of this for
> >> the sake of IO performance. I also recommend to have only one
> >> .modulerc file per modulepath.
> >>
> >> So I would prefer the version-specific configuration information to be
> >> put in .modulerc files. We may analyze what makes this approach more
> >> complex for automated config changes and work on this to ease
> >> automation.
> >>
> >> .modulerc file may also contain code that reads a central registry
> >> file holding all the configuration for all versions, then renders
> >> modulerc commands based on the retrieved configurations.
> >>
> >> # Life cycle
> >>
> >> In addition to hide and forbid, it is also possible to tag
> >> modulefiles. To keep things generic, "unstable" and "deprecated" may
> >> be tags applied to modulefiles.
> >>
> >> What is missing is a way to say that such tag is hidden and the
> >> ability to unveil them but not all the hidden modules.
> >>
> >> A new config option "avail_hide_tagged" may be added to list all tag
> >> that should be hidden on a "module avail". This config option value
> >> may be changed by user if they want to see the modules holding these
> >> specific tags.
> >>
> >> # Availability based on hostname or OS
> >>
> >> Here I would like to challenge if the following existing approaches
> >> can already cover these needs:
> >>
> >> * having specific-modulepaths for the system that only contains the
> >> modulefiles compatible with it
> >> * using "module-virtual" to spawn the modulefile in the modulepath
> >> only if the current system is compatible with it
> >>
> >> # Path manipulations
> >>
> >> I am totally convinced by this. Having a new modulefile command like
> >> "module-autoenv prefix append|prepend" that if defined tests dirs
> >> existence and sets env variables following a mapping defined in a
> >> configuration option. Could be a great addition.
> >>
> >> # Module info messages
> >>
> >> It is stated that "A version-independent message would be useful" on
> >> Modules. module-warn may already target the generic module name to
> >> apply message to any version of this module. So if I have understood
> >> well the need, it is already fulfilled.
> >>
> >> #
> >>
> >> Best,
> >> Xavier
> >>
> >> Le jeu. 16 oct. 2025 à 15:59, Gsell, Achim <ach...@ps...> a écrit :
> >>>
> >>> 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
> >>>
> >>>
> >>> _______________________________________________
> >>> 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 your thoughts/comments!

> On 1 Nov 2025, at 18:37, Xavier Delaruelle <xav...@gm...> wrote:
> 
> To complete my previous email to give my view on how to proceed.
> 
> I think we need to keep exchanging to refine things and build the list
> of features that are currently missing in Modules and need to be
> developed.

I completely agree. We can use the document as basis and refine things there. Would this be ok for you? Or do you have another idea/proposal? 

I added you as collaborator to the Pmodules repository - so you can already edit the document.

Thanks and best,

Achim

> 
> Best,
> Xavier
> 
> Le sam. 1 nov. 2025 à 18:21, Xavier Delaruelle
> <xav...@gm...> a écrit :
>> 
>> Dear Achim,
>> 
>> Many thanks for this insighful document. I have made an initial
>> analysis and below are my first thoughts.
>> 
>> # Module configuration files
>> 
>> As you point there is a strong preference in Modules to have the least
>> possible files to read and even to test for existence. All of this for
>> the sake of IO performance. I also recommend to have only one
>> .modulerc file per modulepath.
>> 
>> So I would prefer the version-specific configuration information to be
>> put in .modulerc files. We may analyze what makes this approach more
>> complex for automated config changes and work on this to ease
>> automation.
>> 
>> .modulerc file may also contain code that reads a central registry
>> file holding all the configuration for all versions, then renders
>> modulerc commands based on the retrieved configurations.
>> 
>> # Life cycle
>> 
>> In addition to hide and forbid, it is also possible to tag
>> modulefiles. To keep things generic, "unstable" and "deprecated" may
>> be tags applied to modulefiles.
>> 
>> What is missing is a way to say that such tag is hidden and the
>> ability to unveil them but not all the hidden modules.
>> 
>> A new config option "avail_hide_tagged" may be added to list all tag
>> that should be hidden on a "module avail". This config option value
>> may be changed by user if they want to see the modules holding these
>> specific tags.
>> 
>> # Availability based on hostname or OS
>> 
>> Here I would like to challenge if the following existing approaches
>> can already cover these needs:
>> 
>> * having specific-modulepaths for the system that only contains the
>> modulefiles compatible with it
>> * using "module-virtual" to spawn the modulefile in the modulepath
>> only if the current system is compatible with it
>> 
>> # Path manipulations
>> 
>> I am totally convinced by this. Having a new modulefile command like
>> "module-autoenv prefix append|prepend" that if defined tests dirs
>> existence and sets env variables following a mapping defined in a
>> configuration option. Could be a great addition.
>> 
>> # Module info messages
>> 
>> It is stated that "A version-independent message would be useful" on
>> Modules. module-warn may already target the generic module name to
>> apply message to any version of this module. So if I have understood
>> well the need, it is already fulfilled.
>> 
>> #
>> 
>> Best,
>> Xavier
>> 
>> Le jeu. 16 oct. 2025 à 15:59, Gsell, Achim <ach...@ps...> a écrit :
>>> 
>>> 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
>>> 
>>> 
>>> _______________________________________________
>>> 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...>]

To complete my previous email to give my view on how to proceed.

I think we need to keep exchanging to refine things and build the list
of features that are currently missing in Modules and need to be
developed.

Best,
Xavier

Le sam. 1 nov. 2025 à 18:21, Xavier Delaruelle
<xav...@gm...> a écrit :
>
> Dear Achim,
>
> Many thanks for this insighful document. I have made an initial
> analysis and below are my first thoughts.
>
> # Module configuration files
>
> As you point there is a strong preference in Modules to have the least
> possible files to read and even to test for existence. All of this for
> the sake of IO performance. I also recommend to have only one
> .modulerc file per modulepath.
>
> So I would prefer the version-specific configuration information to be
> put in .modulerc files. We may analyze what makes this approach more
> complex for automated config changes and work on this to ease
> automation.
>
> .modulerc file may also contain code that reads a central registry
> file holding all the configuration for all versions, then renders
> modulerc commands based on the retrieved configurations.
>
> # Life cycle
>
> In addition to hide and forbid, it is also possible to tag
> modulefiles. To keep things generic, "unstable" and "deprecated" may
> be tags applied to modulefiles.
>
> What is missing is a way to say that such tag is hidden and the
> ability to unveil them but not all the hidden modules.
>
> A new config option "avail_hide_tagged" may be added to list all tag
> that should be hidden on a "module avail". This config option value
> may be changed by user if they want to see the modules holding these
> specific tags.
>
> # Availability based on hostname or OS
>
> Here I would like to challenge if the following existing approaches
> can already cover these needs:
>
> * having specific-modulepaths for the system that only contains the
> modulefiles compatible with it
> * using "module-virtual" to spawn the modulefile in the modulepath
> only if the current system is compatible with it
>
> # Path manipulations
>
> I am totally convinced by this. Having a new modulefile command like
> "module-autoenv prefix append|prepend" that if defined tests dirs
> existence and sets env variables following a mapping defined in a
> configuration option. Could be a great addition.
>
> # Module info messages
>
> It is stated that "A version-independent message would be useful" on
> Modules. module-warn may already target the generic module name to
> apply message to any version of this module. So if I have understood
> well the need, it is already fulfilled.
>
> #
>
> Best,
> Xavier
>
> Le jeu. 16 oct. 2025 à 15:59, Gsell, Achim <ach...@ps...> a écrit :
> >
> > 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
> >
> >
> > _______________________________________________
> > 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,

Many thanks for this insighful document. I have made an initial
analysis and below are my first thoughts.

# Module configuration files

As you point there is a strong preference in Modules to have the least
possible files to read and even to test for existence. All of this for
the sake of IO performance. I also recommend to have only one
.modulerc file per modulepath.

So I would prefer the version-specific configuration information to be
put in .modulerc files. We may analyze what makes this approach more
complex for automated config changes and work on this to ease
automation.

.modulerc file may also contain code that reads a central registry
file holding all the configuration for all versions, then renders
modulerc commands based on the retrieved configurations.

# Life cycle

In addition to hide and forbid, it is also possible to tag
modulefiles. To keep things generic, "unstable" and "deprecated" may
be tags applied to modulefiles.

What is missing is a way to say that such tag is hidden and the
ability to unveil them but not all the hidden modules.

A new config option "avail_hide_tagged" may be added to list all tag
that should be hidden on a "module avail". This config option value
may be changed by user if they want to see the modules holding these
specific tags.

# Availability based on hostname or OS

Here I would like to challenge if the following existing approaches
can already cover these needs:

* having specific-modulepaths for the system that only contains the
modulefiles compatible with it
* using "module-virtual" to spawn the modulefile in the modulepath
only if the current system is compatible with it

# Path manipulations

I am totally convinced by this. Having a new modulefile command like
"module-autoenv prefix append|prepend" that if defined tests dirs
existence and sets env variables following a mapping defined in a
configuration option. Could be a great addition.

# Module info messages

It is stated that "A version-independent message would be useful" on
Modules. module-warn may already target the generic module name to
apply message to any version of this module. So if I have understood
well the need, it is already fulfilled.

#

Best,
Xavier

Le jeu. 16 oct. 2025 à 15:59, Gsell, Achim <ach...@ps...> a écrit :
>
> 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
>
>
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest

Re: [Modules] Use label in "module use"

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

Dear Achim,

Thanks for this proposal. It would be interesting to have some "design
notes" (like those at [1]) for this, to fully understand the need,
describe how it is expected to work and what are all the impacts to
take into account.

Best,
Xavier

[1] https://modules.readthedocs.io/en/latest/design.html

Le mer. 29 oct. 2025 à 14:13, Gsell, Achim <ach...@ps...> a écrit :
>
> Dear Xavier,
>
> I wrote a small patch, so that a label can be used instead of a directory in “module use”. This is equivalent to adding ‘groups’ in Pmodules. If ok, I can open an issue and create a PR for this change.
>
> Best
>
> Achim
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest

[Modules] Use label in "module use"

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

Dear Xavier,

I wrote a small patch, so that a label can be used instead of a directory in “module use”. This is equivalent to adding ‘groups’ in Pmodules. If ok, I can open an issue and create a PR for this change.

Best

Achim