lmod-users — A list to discuss using/deploying Lmod

Re: [Lmod-users] Conda/venv modules

[Guillen C. C. <Car...@lr...>]

Hi Everyone,


in some cases we use inside a module script something like:

set_function("mytool", "source $MYTOOL_PATH/bin/activate; " ..  "$MYTOOL_PATH/bin/mytool \"$@\"; " ..  "deactivate")

this renames or aliases the executables. This activates the environment only when `mytool` is called. We have used this in Tmod, I haven't tried it in Lmod yet...

I think this is a limted approach, you probably don't want to do this when having tons of executables, or executables which may conflict between environments (then the warning from check_python_environment is better. But for some simple packages (with 1 or 2 executables) it does the trick well.


I hope this helps.


Best regards,

Carla


________________________________
Von: Shelly Johnson (she/her) <She...@uv...>
Gesendet: Donnerstag, 9. Juli 2026 15:28
An: lmo...@li...
Betreff: [Lmod-users] Conda/venv modules

Hi All,

Following a discussion during the Lmod-Users meeting on Tuesday about modules that activate Conda environments, I promised to share a function that I created to check for active environments (Conda or venv) before proceeding with loading a module that activates it’s own environment.

The function checks for active Conda or venv environments.  If an active environment is detected, an appropriate message is printed and loading of the module is aborted.

The function is defined and registered to the Lmod sandbox in the SitePackage.lua file as follows:

-- check_python_environment(): Here we check for active conda or venv environments

function check_python_environment(module_name)
    -- This check only needs to run when loading a module
    if mode() ~= "load" then return end

    -- Fetch the environment variables
    local condaLevel = tonumber(os.getenv("CONDA_SHLVL"))
    local virtualEnv = os.getenv("VIRTUAL_ENV")

    -- Check for active Conda environments
    if (condaLevel ~= nil and condaLevel > 0) then
        local condaWarn = string.format([[

    WARNING: %i active Conda environment(s) detected.

    If this virtual environment is active because of a module that you loaded,
    please unload that module with the command 'module unload <module_name>'
    and then load the '%s' module again.

    If you activated this conda environment directly, enter 'conda deactivate'
    until all environments are deactivated and then load the '%s'
    module again.
    ]], condaLevel, module_name, module_name)
        LmodMessage(condaWarn)
        os.exit(1)
    end

    -- Check for active venv environments
    if (virtualEnv ~= nil) then
        local venvWarn = string.format([[

    WARNING: The following active virtual environment has been detected:
        %s

    If this virtual environment is active because of a module that you loaded,
    please unload that module with the command 'module unload <module_name>'
    and then load the '%s' module again.

    If you activated this virtual environment directly, then please enter
    'deactivate' so that no conflicting virtual environments are loaded and
    then load the '%s' module again.
        ]], virtualEnv, module_name, module_name)
        LmodMessage(venvWarn)
        os.exit(1)
    end
end

-- Register function to the Lmod sandbox
sandbox_registration({
    check_python_environment = check_python_environment
})

The function takes an argument that provides the name of the current module or application being loaded that is incorporated into printed message when an active environment is found.  To use the exact module name, perhaps the most obvious choice, then use the first option.  If you might want to specify the app differently in the output, there are other suggested approaches.

To use this function, include the function name and argument, using one of the following 3 approaches, in your module file:

-- Option a: Using the myModuleName() function
check_python_environment(myModuleName())

-- Option b: Specify a string
check_python_environment("my_pkg_name")

-- Option c: Use a local variable for the string
local app = "gubbins"
check_python_environment(app)

The message can be customized as you wish.

Regarding how to activate and deactivate the environment using Lmod, I've tried different approaches to varying success.

For venv environments, I've modified the init scripts to export the PS1 variable, using:

# edit the module function to export the PS1 variable
sed -i.orig 's/$LMOD_CMD/PS1=$PS1 $LMOD_CMD/g' bash

So that, within my module file, I can do something like:

local oldPS1 = os.getenv("PS1")
source_sh("bash", pathJoin(installDir, "turbomole-venv/bin/activate"))
pushenv("PS1","(turbomole-venv) " .. oldPS1)

This seems to work better than using execute {cmd="source /path/to/venv/bin/activate",modeA={"load"}} with execute {cmd="deactivate",modeA={"unload"}}, which did not reliably restore paths and unset variables.


While writing this up, I realized I likely can use a similar approach for Conda modules.  I had been, until now, mostly using the "execute {cmd=" approach to (1) source conda.sh, (2) conda activate, and (3) conda deactivate.  But that required me to subsequently "unset" variables and use "remove_path" to fully return the environment to it's pre-load state.

While having only tested on a single module prior to sending this message, it seems that the following works well for activating a Conda environment and successfully returning the environment to pre-load state upon unloading:

local oldPS1 = os.getenv("PS1")
source_sh("bash", "/path/to/pkgs/miniforge/25.11.0-1/bin/activate /path/to/pkgs/dRep/3.6.2-1/dRep-3.6.2")
pushenv("PS1","(dRep-3.6.2) " .. oldPS1)

Again, this is not thoroughly tested, but I'm cautiously optimistic that it will be generally reliable for Conda environments.  Hopefully, the above description/examples make sense.  Happy to elaborate or clarify further, if needed. Has anyone found a better or more efficient solution that they recommend?

Best,
Shelly

[Lmod-users] Conda/venv modules

[Shelly J. (she/her) <She...@uv...>]

Hi All,

Following a discussion during the Lmod-Users meeting on Tuesday about modules that activate Conda environments, I promised to share a function that I created to check for active environments (Conda or venv) before proceeding with loading a module that activates it’s own environment.

The function checks for active Conda or venv environments.  If an active environment is detected, an appropriate message is printed and loading of the module is aborted.

The function is defined and registered to the Lmod sandbox in the SitePackage.lua file as follows:

-- check_python_environment(): Here we check for active conda or venv environments

function check_python_environment(module_name)
    -- This check only needs to run when loading a module
    if mode() ~= "load" then return end

    -- Fetch the environment variables
    local condaLevel = tonumber(os.getenv("CONDA_SHLVL"))
    local virtualEnv = os.getenv("VIRTUAL_ENV")

    -- Check for active Conda environments
    if (condaLevel ~= nil and condaLevel > 0) then
        local condaWarn = string.format([[

    WARNING: %i active Conda environment(s) detected.

    If this virtual environment is active because of a module that you loaded,
    please unload that module with the command 'module unload <module_name>'
    and then load the '%s' module again.

    If you activated this conda environment directly, enter 'conda deactivate'
    until all environments are deactivated and then load the '%s'
    module again.
    ]], condaLevel, module_name, module_name)
        LmodMessage(condaWarn)
        os.exit(1)
    end

    -- Check for active venv environments
    if (virtualEnv ~= nil) then
        local venvWarn = string.format([[

    WARNING: The following active virtual environment has been detected:
        %s

    If this virtual environment is active because of a module that you loaded,
    please unload that module with the command 'module unload <module_name>'
    and then load the '%s' module again.

    If you activated this virtual environment directly, then please enter
    'deactivate' so that no conflicting virtual environments are loaded and
    then load the '%s' module again.
        ]], virtualEnv, module_name, module_name)
        LmodMessage(venvWarn)
        os.exit(1)
    end
end

-- Register function to the Lmod sandbox
sandbox_registration({
    check_python_environment = check_python_environment
})

The function takes an argument that provides the name of the current module or application being loaded that is incorporated into printed message when an active environment is found.  To use the exact module name, perhaps the most obvious choice, then use the first option.  If you might want to specify the app differently in the output, there are other suggested approaches.

To use this function, include the function name and argument, using one of the following 3 approaches, in your module file:

-- Option a: Using the myModuleName() function
check_python_environment(myModuleName())

-- Option b: Specify a string
check_python_environment("my_pkg_name")

-- Option c: Use a local variable for the string
local app = "gubbins"
check_python_environment(app)

The message can be customized as you wish.

Regarding how to activate and deactivate the environment using Lmod, I've tried different approaches to varying success.

For venv environments, I've modified the init scripts to export the PS1 variable, using:

# edit the module function to export the PS1 variable
sed -i.orig 's/$LMOD_CMD/PS1=$PS1 $LMOD_CMD/g' bash

So that, within my module file, I can do something like:

local oldPS1 = os.getenv("PS1")
source_sh("bash", pathJoin(installDir, "turbomole-venv/bin/activate"))
pushenv("PS1","(turbomole-venv) " .. oldPS1)

This seems to work better than using execute {cmd="source /path/to/venv/bin/activate",modeA={"load"}} with execute {cmd="deactivate",modeA={"unload"}}, which did not reliably restore paths and unset variables.


While writing this up, I realized I likely can use a similar approach for Conda modules.  I had been, until now, mostly using the "execute {cmd=" approach to (1) source conda.sh, (2) conda activate, and (3) conda deactivate.  But that required me to subsequently "unset" variables and use "remove_path" to fully return the environment to it's pre-load state.

While having only tested on a single module prior to sending this message, it seems that the following works well for activating a Conda environment and successfully returning the environment to pre-load state upon unloading:

local oldPS1 = os.getenv("PS1")
source_sh("bash", "/path/to/pkgs/miniforge/25.11.0-1/bin/activate /path/to/pkgs/dRep/3.6.2-1/dRep-3.6.2")
pushenv("PS1","(dRep-3.6.2) " .. oldPS1)

Again, this is not thoroughly tested, but I'm cautiously optimistic that it will be generally reliable for Conda environments.  Hopefully, the above description/examples make sense.  Happy to elaborate or clarify further, if needed. Has anyone found a better or more efficient solution that they recommend?

Best,
Shelly

[Lmod-users] Tomorrow: Lmod Monthly Zoom Meeting July 7th at 9:30 US Central (14:30 UTC)

[Robert M. <rt...@gm...>]

The Monthly meeting is upon us.  Lets meet Tuesday July 7th at 9:30am
(14:30 UTC)

The Agenda is:

   - Adding new command "module last_error" to upcoming version
   - Fixing unbound LD_LIBRARY_PATH in bash and t/csh
   - Tale of woe: Protecting Lmod for t/csh users
   - No-help from Gemini AI browser (The AI follies)
   - "module show" and os.getenv("var") that depends on other modules
   - Termwidth? and broken ttys.
   - Probably other interesting topics

The Zoom coordinates are:
 Join Zoom Meeting
https://utexas.zoom.us/j/82658343352

Meeting ID: 826 5834 3352

The full agenda can be found here:
https://hackmd.io/d8TELXOWT-qhF8eaaNG4NA

Please feel free to attend.  Beginners welcome.

Best,
The Lmod Team

[Lmod-users] Tomorrow: Lmod Zoom Meeting June 2nd at 9:30 US Central (14:30 UTC)

[Robert M. <rt...@gm...>]

We will have our zoom meeting tomorrow (June 2nd) at 9:30 US Central (14:30
UTC)

Taylor Ishisaka  will be hosting the meeting
Join Zoom Meeting
https://utexas.zoom.us/j/82658343352

Meeting ID: 826 5834 3352

The Agenda is:

The agenda can be found here: https://hackmd.io/LdOSEToyR8qkJf9uD3tAkQ

An outline of the agenda:

   - PR #814 A Gentoo Developer gets different results for load test
   - Issue #823: (Related to #805) Suggestions for loading a failed module
   - Issue #820: Report "Last-error":
   - Issue #817: Removing `.` prefix
   - Issue #815: list by family: Chris Ramos has volunteered
   - Issue #813: module name with just Spaces
   - Issue #812: LD_LIBRARY_PATH, LD_PRELOAD protection
   - Issue #818: module-virtual
   -  Q/A

You do not have to be an Lmod Expert to attend.  Beginners welcome.

Best
Lmod Team

[Lmod-users] Tomorrow: Lmod Monthly Zoom Meeting at 9:30 US Central (14:30 UTC)

[Robert M. <rt...@gm...>]

We will have our monthly zoom meeting tomorrow at 9:30 Central

The zoom link: https://utexas.zoom.us/j/82658343352

The agenda can be found here:
https://hackmd.io/PI-gfmgQRgSGdUTWcFrgRw

There are a few things to discuss:


   - Issue #813: Havoc cause with a file named " "
   - Issue #812: Protecting Lmod from changes to LD_LIBRARY_PATH, LD_PRELOAD
   - Issue #816: List modules associated with "family"
   - Easy Build User's Meeting in Portugal in April

See you there tomorrow,
Lmod Team

[Lmod-users] Robert McLay will be speaking at EasyBuild User Meeting '26 on Lmod Updates

[Robert M. <rt...@gm...>]

I'll be speaking at EUM '26 on Lmod updates at 16:15 16;45 (UTC+1)  or
10:15 to 10:45 US Central.

All talks will be recorded and live streamed via
https://www.youtube.com/@easybuilders

Details on EUM '26 can be found here: https://easybuild.io/eum26/

Best,
Robert McLay

[Lmod-users] [Bug] module show does not escape double quotes inside execute{cmd=...}

[Hongyi Z. <hon...@gm...>]

Hi Lmod team,

When an execute{} directive contains embedded double quotes in its cmd
string, `module show` renders them unescaped, producing output that
cannot be copy-pasted or parsed correctly.

Reproducer:

```lua
local datasci_bin = pathJoin(os.getenv("HOME"), ".pyenv/versions/datasci/bin")
local pyenv_init = '[[ -d "' .. datasci_bin .. '" ]] || bash
${HOME}/init.bash 2>/dev/null'
execute{cmd=pyenv_init, modeA={"load"}}
```

`module show` output:

```
execute{cmd="[[ -d "/home/werner/.pyenv/versions/datasci/bin" ]] ||
bash ${HOME}/init.bash 2>/dev/null", modeA={"load"}}
```

The inner double quotes around the path are not escaped, so the
displayed string has mismatched quotes. The actual execution works
correctly — the cmd string is passed to the shell verbatim and eval'd
without issue. This is purely a display/serialization problem in
`module show`.

Looking at the source (src/MC_Show.lua, locatable via `ug -B5 -A10
"function M.execute" src/MC_Show.lua`), the implementation simply
concatenates the cmd string between literal double quotes without
escaping any embedded quotes:

```lua
function M.execute(self, t)
   local a = {}
   a[#a+1] = "execute{cmd=\""
   a[#a+1] = t.cmd
   a[#a+1] = "\", modeA={\""
   a[#a+1] = concatTbl(t.modeA, "\", \"")
   a[#a+1] = "\"}}"
   A[#A+1] = concatTbl(a,"")
end
```

A fix would be to escape embedded double quotes in `t.cmd` before
concatenation, e.g.:

```lua
a[#a+1] = t.cmd:gsub('"', '\\"')
```

Environment:
- Lmod 8.7.x (built from git)
- Ubuntu 22.04.5 LTS
- Lua 5.1

Thanks,
Zhao
-- 
Assoc. Prof. Hongsheng Zhao <hon...@gm...>
Theory and Simulation of Materials
Hebei Vocational University of Technology and Engineering
No. 473, Quannan West Street, Xindu District, Xingtai, Hebei province

[Lmod-users] Lmod 9.2 released

[Robert M. <rt...@gm...>]

Lmod 9.2 has been released.  The main reason for this release is that Lmod
now supports Lua 5.5.
Lmod 9.2 will work with all versions of Lua so it is safe to run anywhere.

However, Lmod depends on Luaposix and that the currently maintained version
of Luaposix does not support Lua 5.5. This is mainly for Fedora Rawhide as
it has a patched version of Luaposix that will work with Lua 5.5

The upshot of this is it's safe to run Lmod 9.2 anywhere.  However it is
not safe to install Lua 5.5 on your system unless luaposix works with Lua
5.5 on your system.

Best,
The Lmod Team

[Lmod-users] Tomorrow: April 7th Lmod Zoom Meeting at 9:30 am (Central)

[Robert M. <rt...@gm...>]

The Lmod meeting will be tomorrow at 9:30 am (14:30 UTC).  The zoom link is:

https://utexas.zoom.us/j/82658343352

The Agenda:

   - Lua 5.5 released and the changes that it brings
   - Support for luaposix w.r.t. Lua 5.5
   - Fixing Lmod to support Lua 5.5
   - HPSF '26 presentation
   - Upcoming EUM '26 presentation
   - Q/A

The complete agenda can be found here:
https://hackmd.io/9pSjQ1m-QrOCm9RZ5pPqjA?view
You do not have to be an Lmod expert.  Beginner Questions  welcome

Best
The Lmod Team

Re: [Lmod-users] Difference between bash and cshell for source_sh

[Robert M. <rt...@gm...>]

Since you have not received a response, it would seem that no one else has
solved the problem either.

Please create an issue at github with this.  In this issue please report
what the output of the following is:

bash> $LMOD_CMD csh load conda 2>&1 > conda_load.log
bash> $LMOD_CMD csh load conda_env 2>&1 > conda_env_load.log
bash> $LMOD_CMD csh load conda conda_env 2>&1 > big_conda_load.log

Please attach the above three log files to the github issue.

Thanks,
Robert.


On Mon, Mar 16, 2026 at 10:56 AM Jakob Stierhof <jak...@fa...>
wrote:

> Dear Lmod users,
>
> at our site we provide the users with a conda installation via lmod.
> While this works fine, we also have some locally compiled code that
> depends on python and we use conda environments for it. We managed to
> activate and deactivate a specific conda env via a module file doing
> nothing else other than having a `execute{cmd='conda activate {env}',
> modeA={'load'}}` and correspondingly for unload.
>
> This works as expected in the shell (provided the conda module is loaded
> and not requiested via, e.g., `depends_on`, i.e., set as `prereq`).
> However, when the module for the conda environment is used in another
> module file it does work as expected using bash, but it fails for cshell.
>
> The problem is not because of lmod, but because how conda initializes
> for bash or cshell. In the latter case the `conda activate` throws an
> error `CondaError: Run 'conda init' before 'conda activate`. I suspect
> that the way how lmod modifies the environment interferes with how conda
> wants it to be when running.
>
> So, in short:
>
> cshell> module load conda
> cshell> module load conda_env
>
> works, while
>
> cshell> module load conda conda_env
>
> does not.
>
> For bash, both work just fine.
>
> I was wondering if someone tried to solve a similar issue and came up
> with a good solution.
>
> Thanks!
> Jakob
>
>
>
> _______________________________________________
> Lmod-users mailing list
> Lmo...@li...
> https://lists.sourceforge.net/lists/listinfo/lmod-users
>

[Lmod-users] Difference between bash and cshell for source_sh

[Jakob S. <jak...@fa...>]

Dear Lmod users,

at our site we provide the users with a conda installation via lmod. 
While this works fine, we also have some locally compiled code that 
depends on python and we use conda environments for it. We managed to 
activate and deactivate a specific conda env via a module file doing 
nothing else other than having a `execute{cmd='conda activate {env}', 
modeA={'load'}}` and correspondingly for unload.

This works as expected in the shell (provided the conda module is loaded 
and not requiested via, e.g., `depends_on`, i.e., set as `prereq`). 
However, when the module for the conda environment is used in another 
module file it does work as expected using bash, but it fails for cshell.

The problem is not because of lmod, but because how conda initializes 
for bash or cshell. In the latter case the `conda activate` throws an 
error `CondaError: Run 'conda init' before 'conda activate`. I suspect 
that the way how lmod modifies the environment interferes with how conda 
wants it to be when running.

So, in short:

cshell> module load conda
cshell> module load conda_env

works, while

cshell> module load conda conda_env

does not.

For bash, both work just fine.

I was wondering if someone tried to solve a similar issue and came up 
with a good solution.

Thanks!
Jakob

[Lmod-users] Lmod Zoom Mtg March 3rd, 2026

[Matthew C. <mc...@ta...>]

We will hold the next Lmod Zoom meeting on March 3rd at 9:30 US Central Time (15:30 UTC).

The current agenda is:

  *
Issue #805: suggestion follow-up
  *
Issue #806: fix installed library files
  *
Issue #807: Lua 5.5 support
  *
Issue #808: describe() support for collections
  *
main: improved multiline “unknown error” messaging for multi-module requests (prereq-load hint)
  *
User Q&A

Beginners welcome.  You do not need to be an Lmod expert to attend the meeting.  New topics welcome.

The Zoom link is:
https://utexas.zoom.us/my/mcawood

Best,
Lmod Team

[Lmod-users] Tomorrow: Lmod Monthly Zoom Meeting at 9:30 US Central (15:30 UTC)

[Robert M. <rt...@gm...>]

Tomorrow we will have our Monthly Zoom Meeting at 9:30 US Central (15:30
UTC)

Agenda:

* Q/A
* Upcoming Presentation at EUM '26
* Issue #788: Markdown Support Feedback
* Issue #804: Show command to load when using software hierarchy


Zoom Link:
https://us04web.zoom.us/j/2193049324?pwd=meA1uTMrZOWOs3dDBUbCwQrf6rAeKV.1&omn=78993258470

Re: [Lmod-users] Hooking lmod methods

[<mal...@ci...>]

Hey, 
thanks for your inputs, 
I ended up using SitePackage with a sandbox table modification as you hinted. And it works like a charm. 

The goal if this SitePackage usage is to workaround some vendor generated modules that dont play well with our site's policy (it append_path in the wrong environment variable). By hooking prepend_path through SitePackage, we avoid module modification. 

Cheers, 
Etienne 

De: "Ward Poelmans" <wpo...@gm...> 
À: "lmod-users" <lmo...@li...> 
Envoyé: Jeudi 5 Février 2026 21:07:46 
Objet: Re: [Lmod-users] Hooking lmod methods 

On Thu, Feb 5, 2026 at 8:04 PM Ward Poelmans < [ mailto:wpo...@gm... | wpo...@gm... ] > wrote: 


> I'm not sure I understand what you try to achieve but the 
> SitePackage.lua is quite reliable. We put it at 
> /etc/lmod/SitePackage.lua where it gets picked up by Lmod. We've never 
> seen issue with this, no matter how creative the users are. 

I missed the crucial bit: the file /etc/lmod/lmod_config.lua is read by Lmod. There you can tell it where to look for SitePackage.lua: 
require("strict") 
local cosmic = require("Cosmic"):singleton() 
cosmic:assign("LMOD_PACKAGE_PATH", "/etc/lmod") 

This makes Lmod look into /etc/lmod for the file SitePackage.lua 

Ward 



_______________________________________________ 
Lmod-users mailing list 
Lmo...@li... 
https://lists.sourceforge.net/lists/listinfo/lmod-users 

Re: [Lmod-users] Hooking lmod methods

[Ward P. <wpo...@gm...>]

On Thu, Feb 5, 2026 at 8:04 PM Ward Poelmans <wpo...@gm...> wrote:


> I'm not sure I understand what you try to achieve but the
> SitePackage.lua is quite reliable. We put it at
> /etc/lmod/SitePackage.lua where it gets picked up by Lmod. We've never
> seen issue with this, no matter how creative the users are.

I missed the crucial bit: the file /etc/lmod/lmod_config.lua is read by
Lmod. There you can tell it where to look for SitePackage.lua:
require("strict")
local cosmic = require("Cosmic"):singleton()
cosmic:assign("LMOD_PACKAGE_PATH", "/etc/lmod")

This makes Lmod look into /etc/lmod for the file SitePackage.lua

Ward

Re: [Lmod-users] Hooking lmod methods

[Ward P. <wpo...@gm...>]

Hi Etienne,

On Wed, Feb 4, 2026 at 10:45 AM <mal...@ci...> wrote:

> This works like a charm (so it seems), but it is easy fora user to usnet the LMOD site package env variable and so its brittle. I think I'm goingto stay with SitePackage, but is there a wait to make the solution above work ? Or an alternative way of doing this whole "shenanigans".
> I'm very much looking for advice or more conventional ways of doing that. The fact is that we have a lot of common things between our modules and wish to factorize.

I'm not sure I understand what you try to achieve but the
SitePackage.lua is quite reliable. We put it at
/etc/lmod/SitePackage.lua where it gets picked up by Lmod. We've never
seen issue with this, no matter how creative the users are.

If you want to factor out thing, use the sandbox and register it as a
custom function to use in a module file?

Ward

[Lmod-users] Hooking lmod methods

[<mal...@ci...>]

Hey, I hope this finds you well,

I'm trying to hook prepend_path & append_path so that if a given environment variable is used, I also append it into another variable.

--------
prepend_path( "LD_LIBRARY_PATH","/opt/apps/ddt/5.0.1/lib") becomes:
prepend_path( "LD_LIBRARY_PATH","/opt/apps/ddt/5.0.1/lib")
prepend_path( "MY_OTHER_VARIABLE","/opt/apps/ddt/5.0.1/lib")
--------

The code doing this hooking like like that:

--------
local function Main(context)
    local function HookPathMethods(function_name, source, target)
        local original_alter_path = context[function_name]
        local alter_path = function(...)
            local parameters = {...}
            if parameters[1] == source then
                parameters[1] = target
                original_alter_path(table.unpack(parameters))
            end
            return original_alter_path(...)
        end
        context[function_name] = alter_path
    end
    HookPathMethods("prepend_path", "LD_LIBRARY_PATH", "MY_LD_LIBRARY_PATH")
    HookPathMethods("append_path", "LD_LIBRARY_PATH", "MY_LD_LIBRARY_PATH")
end
return { Main = Main }
--------

Now, I currently have this code,  which is injected through:
--------
assert(loadfile("/path/to/hook.lua"))().Main(_ENV)
--------

This does not work when purging modules, the effect of the hooked prepend_path path remains. I then tried using the sitePackage.lua, like so:

--------
local function HookPathMethods(function_name, source, target)
    local original_function = _ENV[function_name]
    return function(...)
        local parameters = {...}
        if parameters[1] == source then
            parameters[1] = target
            original_function(table.unpack(parameters))
        end
        return original_function(...)
    end
end
sandbox_registration{
    prepend_path = HookPathMethods("prepend_path", "LD_LIBRARY_PATH", "MY_LD_LIBRARY_PATH"),
    append_path = HookPathMethods("append_path", "LD_LIBRARY_PATH", "MY_LD_LIBRARY_PATH")
}
--------

This works like a charm (so it seems), but it is easy fora user to usnet the LMOD site package env variable and so its brittle. I think I'm goingto stay with SitePackage, but is there a wait to make the solution above work ? Or an alternative way of doing this whole "shenanigans".
I'm very much looking for advice or more conventional ways of doing that. The fact is that we have a lot of common things between our modules and wish to factorize.

Have a nice day, regards,
-- 
Etienne Malaboeuf 
Ingénieur de recherche HPC, Département Calcul Intensif (DCI) 

Centre Informatique National de l'Enseignement Supérieur (CINES) 
950 rue de Saint Priest, 34097 Montpellier 
tel : (334) 67 14 14 02 
web : https://www.cines.fr | https://dci.dci-gitlab.cines.fr/webextranet

[Lmod-users] Release of Lmod 9.0.6: Support for hideRegex and forbidRegex in modulerc files

[Robert M. <rt...@gm...>]

Lmod 9.0.6 has been released.  You can now add hideRegex and forbidRegex to
specify module files using Lua-based regular expressions.  Remember that
'%' is used to quote rather than backslash.  Also that '-' (minus sign) is
a special regular expression character.

Best,
Lmod Team

Re: [Lmod-users] Lmod Zoom Mtg Jan 20th, 2026

[Matthew C. <mc...@ta...>]

Reminder that we will have an Lmod meeting tomorrow. Details below.

Best,
Lmod team



________________________________
From: Matthew Cawood <mc...@ta...>
Sent: Monday, January 12, 2026 3:13:19 PM
To: lmod-users <lmo...@li...>
Subject: [Lmod-users] Lmod Zoom Mtg Jan 20th, 2026

We will hold the next Lmod Zoom meeting  Jan. 20th at 9:30 US Central Time (15:30 UTC).

The zoom link is:

https://utexas.zoom.us/my/mcawood

Beginners welcome.  You do not need to be an Lmod expert to attend the meeting.  New topics welcome.

The current agenda is:


  *
Lmod 9 updates
  *
Issue #780: Cached loads
  *
MrPackMod<https://github.com/VictorEijkhout/MrPackMod> Package installer with LMod integration
  *
User Q&A

Best,
Lmod Team

[Lmod-users] Lmod Zoom Mtg Jan 20th, 2026

[Matthew C. <mc...@ta...>]

We will hold the next Lmod Zoom meeting  Jan. 20th at 9:30 US Central Time (15:30 UTC).

The zoom link is:

https://utexas.zoom.us/my/mcawood

Beginners welcome.  You do not need to be an Lmod expert to attend the meeting.  New topics welcome.

The current agenda is:


  *
Lmod 9 updates
  *
Issue #780: Cached loads
  *
MrPackMod<https://github.com/VictorEijkhout/MrPackMod> Package installer with LMod integration
  *
User Q&A

Best,
Lmod Team

Re: [Lmod-users] Query regarding Lua sandbox limitations and executing arbitrary Lua code in modulefiles.

[Matthew C. <mc...@ta...>]

Hi Zhao,

Lmod always executes modulefiles inside a restricted sandbox; there is no setting to allow full Lua execution directly in a modulefile. To run unrestricted Lua, place your logic in SitePackage.lua (which is not sandboxed) and expose selected functions to modulefiles via sandbox_registration. This is the supported way to grant modulefiles controlled access to full Lua. Modifying src/sandbox.lua to loosen restrictions is possible but unsafe and not recommended. For details, see the “SitePackage.lua and the Sandbox” section of the Lmod documentation. If you share what functionality you need, I can suggest the safest approach.

Best,
Matthew

From: Hongyi Zhao <hon...@gm...>
Date: Monday, December 1, 2025 at 19:44
To: lmod-users <lmo...@li...>
Subject: [Lmod-users] Query regarding Lua sandbox limitations and executing arbitrary Lua code in modulefiles.

Dear Robert and the Lmod community,

It appears that Lmod runs modulefiles within a restricted sandbox
environment, limiting access to the full standard Lua library (e.g.,
certain `os.*` or `io.*` functions).
Is there a configuration option or a specific method to allow the
execution of **arbitrary/full Lua code** directly within a `.lua`
modulefile?

Best regards,
Zhao
--
Assoc. Prof. Hongsheng Zhao <hon...@gm...>
Theory and Simulation of Materials
Hebei Vocational University of Technology and Engineering
No. 473, Quannan West Street, Xindu District, Xingtai, Hebei province


_______________________________________________
Lmod-users mailing list
Lmo...@li...
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Flmod-users&data=05%7C02%7C%7Cb9ca750255ac46f0070608de314453cd%7C31d7e2a5bdd8414e9e97bea998ebdfe1%7C0%7C0%7C639002366699830382%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=LjpMAdMkyUbd6df7o054X8MTkd%2Bu93yxUd5H%2BrzFVZw%3D&reserved=0<https://lists.sourceforge.net/lists/listinfo/lmod-users>
>> This message is from an external sender. Learn more about why this <<
>> matters at https://links.utexas.edu/rtyclf.                        <<

[Lmod-users] Query regarding Lua sandbox limitations and executing arbitrary Lua code in modulefiles.

[Hongyi Z. <hon...@gm...>]

Dear Robert and the Lmod community,

It appears that Lmod runs modulefiles within a restricted sandbox
environment, limiting access to the full standard Lua library (e.g.,
certain `os.*` or `io.*` functions).
Is there a configuration option or a specific method to allow the
execution of **arbitrary/full Lua code** directly within a `.lua`
modulefile?

Best regards,
Zhao
-- 
Assoc. Prof. Hongsheng Zhao <hon...@gm...>
Theory and Simulation of Materials
Hebei Vocational University of Technology and Engineering
No. 473, Quannan West Street, Xindu District, Xingtai, Hebei province

Re: [Lmod-users] Dynamically generate a modulefile from a bash script and then load/unload it.

[Hongyi Z. <hon...@gm...>]

On Fri, Nov 21, 2025 at 7:37 PM Hongyi Zhao <hon...@gm...> wrote:
>
> Hi there,
>
> I want to dynamically generate a modulefile from a bash script and
> then load/unload it. The reason why I plan to do this is: I can
> directly modify the corresponding bash script without rewriting and
> manually generating the corresponding modulefile. See below for the
> details:
>
> The lua module file is as follows:
>
> ```
> $ cat Public/repo/github.com/TACC/modulefiles/applications/Homebrew/brew.git.lua
> help([[Loads Homebrew environment]])
>
> whatis("Loads Homebrew package manager")
>
> if (mode() == "load") then
>     -- Get the directory containing this module file
>     local script_dir = myFileName():match("(.*/)")
>
>     -- Run sh_to_modulefile and capture output
>     local handle = io.popen("sh_to_modulefile --cleanEnv --from=bash
> --to=lua " .. script_dir .. "load.bash")
>     local lua_code = handle:read("*a")
>     handle:close()
>
>     -- Write to temporary file
>     local tmpfile = os.tmpname()
>     local f = io.open(tmpfile, "w")
>     f:write(lua_code)
>     f:close()
>
>     -- Execute via dofile (correct scope)
>     dofile(tmpfile)
>
>     -- Cleanup
>     os.remove(tmpfile)
> end
>
> -- Note: No unload section needed
> -- Lmod automatically reverses all setenv(), prepend_path(), and
> set_shell_function() calls
> ```
> And the bash script is as follows:
>
> ```
> $ cat Public/repo/github.com/TACC/modulefiles/applications/Homebrew/load.bash
> #!/bin/bash
> # Homebrew environment initialization script
> # This script is automatically converted to Lmod module format by
> sh_to_modulefile
> # All environment variables set here will be automatically tracked and
> cleaned up on module unload
>
> brew_prefix="/home/linuxbrew/.linuxbrew"
>
> # Load Homebrew's core environment variables (PATH, HOMEBREW_PREFIX, etc.)
> eval "$($brew_prefix/bin/brew shellenv)"
>
> # Load bash completion for brew commands
> . "$brew_prefix/etc/bash_completion.d/brew"
>
> # Add Homebrew library paths for runtime linking and pkg-config
> export LD_LIBRARY_PATH="$brew_prefix/lib:${LD_LIBRARY_PATH}"
> export PKG_CONFIG_PATH="$brew_prefix/lib/pkgconfig:${PKG_CONFIG_PATH}"
>
> # Prevent automatic cleanup to preserve installed packages
> export HOMEBREW_NO_INSTALL_CLEANUP=1
> ```
>
> Then I tried to load it as follows, but failed:
>
> ```
> $ module load Homebrew/brew.git
> Lmod has detected the following error:  Unable to load module because
> of error when evaluating modulefile:
>      /home/werner/Public/repo/github.com/TACC/modulefiles/applications/Homebrew/brew.git.lua:
> [string "help([[Loads Homebrew environment]])..."]:15: attempt to call
> field 'tmpname' (a nil value)
>      Please check the modulefile and especially if there is a line
> number specified in the above message
> While processing the following module(s):
>     Module fullname    Module Filename
>     ---------------    ---------------
>     Homebrew/brew.git
> /home/werner/Public/repo/github.com/TACC/modulefiles/applications/Homebrew/brew.git.lua
> ```
>
> I wonder if my above idea can be implemented based on lmod? Are there
> any hints or methods to solve this problem?

I finally figured out the following method, which solves the above problem:

```
$ cat Public/repo/github.com/TACC/modulefiles/applications/Homebrew/brew.git.lua
help([[Loads Homebrew environment]])
whatis("Loads Homebrew package manager")

-- 1. Define script-wide variables
-- These variables are local to this file but accessible throughout the script
local brew_prefix = "/home/linuxbrew/.linuxbrew"
local script_dir  = myFileName():match("(.*/)")
local bash_script = script_dir .. "load.bash"

-- 2. Load environment variables (PATH, MANPATH, etc.)
-- Lmod executes load.bash and captures env changes
source_sh("bash", bash_script)

-- 3. Bash completion settings
if (myShellName() == "bash") then
    local completion_file = brew_prefix .. "/etc/bash_completion.d/brew"
    -- Bash requires explicitly sourcing the completion file.
    -- The 'execute' function runs the command directly in the user's shell,
    -- bypassing Lmod's internal parsing for better performance.
    execute{cmd="source " .. completion_file, modeA={"load"}}
end

-- 4. Zsh completion settings
-- Note regarding Zsh completion:
-- Zsh users usually have 'autoload -Uz compinit && compinit' in their .zshrc.
-- If the module is loaded *after* shell startup, the completion might
not update
-- immediately because 'compinit' has already run with the old fpath.
-- However, prepending "fpath" is the standard and correct practice for modules.
if (myShellName() == "zsh") then
    -- Zsh only needs the directory added to fpath.
    -- No need to point to a specific file or use execute.
    local zsh_site_functions = brew_prefix .. "/share/zsh/site-functions"
    prepend_path("fpath", zsh_site_functions)
end

$ cat Public/repo/github.com/TACC/modulefiles/applications/Homebrew/load.bash
#!/bin/bash
# This script only handles Environment Variables.
# It is designed to be called by Lmod's source_sh function.

brew_prefix="/home/linuxbrew/.linuxbrew"

# 1. Let brew set core variables (PATH, MANPATH, INFOPATH, etc.)
eval "$($brew_prefix/bin/brew shellenv)"

# 2. Set additional variables
export LD_LIBRARY_PATH="$brew_prefix/lib:${LD_LIBRARY_PATH}"
export PKG_CONFIG_PATH="$brew_prefix/lib/pkgconfig:${PKG_CONFIG_PATH}"
export HOMEBREW_NO_INSTALL_CLEANUP=1
```

Regards,
Zhao

[Lmod-users] Dynamically generate a modulefile from a bash script and then load/unload it.

[Hongyi Z. <hon...@gm...>]

Hi there,

I want to dynamically generate a modulefile from a bash script and
then load/unload it. The reason why I plan to do this is: I can
directly modify the corresponding bash script without rewriting and
manually generating the corresponding modulefile. See below for the
details:

The lua module file is as follows:

```
$ cat Public/repo/github.com/TACC/modulefiles/applications/Homebrew/brew.git.lua
help([[Loads Homebrew environment]])

whatis("Loads Homebrew package manager")

if (mode() == "load") then
    -- Get the directory containing this module file
    local script_dir = myFileName():match("(.*/)")

    -- Run sh_to_modulefile and capture output
    local handle = io.popen("sh_to_modulefile --cleanEnv --from=bash
--to=lua " .. script_dir .. "load.bash")
    local lua_code = handle:read("*a")
    handle:close()

    -- Write to temporary file
    local tmpfile = os.tmpname()
    local f = io.open(tmpfile, "w")
    f:write(lua_code)
    f:close()

    -- Execute via dofile (correct scope)
    dofile(tmpfile)

    -- Cleanup
    os.remove(tmpfile)
end

-- Note: No unload section needed
-- Lmod automatically reverses all setenv(), prepend_path(), and
set_shell_function() calls
```
And the bash script is as follows:

```
$ cat Public/repo/github.com/TACC/modulefiles/applications/Homebrew/load.bash
#!/bin/bash
# Homebrew environment initialization script
# This script is automatically converted to Lmod module format by
sh_to_modulefile
# All environment variables set here will be automatically tracked and
cleaned up on module unload

brew_prefix="/home/linuxbrew/.linuxbrew"

# Load Homebrew's core environment variables (PATH, HOMEBREW_PREFIX, etc.)
eval "$($brew_prefix/bin/brew shellenv)"

# Load bash completion for brew commands
. "$brew_prefix/etc/bash_completion.d/brew"

# Add Homebrew library paths for runtime linking and pkg-config
export LD_LIBRARY_PATH="$brew_prefix/lib:${LD_LIBRARY_PATH}"
export PKG_CONFIG_PATH="$brew_prefix/lib/pkgconfig:${PKG_CONFIG_PATH}"

# Prevent automatic cleanup to preserve installed packages
export HOMEBREW_NO_INSTALL_CLEANUP=1
```

Then I tried to load it as follows, but failed:

```
$ module load Homebrew/brew.git
Lmod has detected the following error:  Unable to load module because
of error when evaluating modulefile:
     /home/werner/Public/repo/github.com/TACC/modulefiles/applications/Homebrew/brew.git.lua:
[string "help([[Loads Homebrew environment]])..."]:15: attempt to call
field 'tmpname' (a nil value)
     Please check the modulefile and especially if there is a line
number specified in the above message
While processing the following module(s):
    Module fullname    Module Filename
    ---------------    ---------------
    Homebrew/brew.git
/home/werner/Public/repo/github.com/TACC/modulefiles/applications/Homebrew/brew.git.lua
```

I wonder if my above idea can be implemented based on lmod? Are there
any hints or methods to solve this problem?

Regards,
Zhao
-- 
Assoc. Prof. Hongsheng Zhao <hon...@gm...>
Theory and Simulation of Materials
Hebei Vocational University of Technology and Engineering
No. 473, Quannan West Street, Xindu District, Xingtai, Hebei province

[Lmod-users] Lmod 9.0 released

[Robert M. <rt...@gm...>]

I am happy to release the long awaited version 9.0.  This is a small change
from 8.7.67 but a big change from earlier versions.

Here is a list of the major changes since Lmod 8.0:


   1. Irreversible mode: Unloading a module can set env. vars
   2. Improved optional module tracking.
   3. More powerful hide{} and forbid{} functions to hide and forbid
   modules.
   4. The function depends_on_any() added.
   5. Collection only written to ~/.config/lmod directory.
   6. Great performance improvements when loading a module with many
   dependencies.

Enjoy this latest version of Lmod.
The Lmod Team.