I am seeing an Lmod failure with generated Lua modulefiles when modextravars references an environment variable that is set by another module.
The concrete case is Triton/3.3.1-gfbf-2024a-CUDA-12.6.0, which generates lines like:
setenv("TRITON_CUOBJDUMP_PATH", os.getenv("CUDA_HOME") .. "/bin/cubjdump")
setenv("TRITON_LIBDEVICE_PATH", os.getenv("CUDA_HOME") .. "/nvvm/libdevice/libdevice.10.bc")
This works while CUDA_HOME is set by the CUDA module, but the generated Triton modulefile itself is fragile: evaluating it without CUDA_HOME already fails. For example:
module show Triton/3.3.1-gfbf-2024a-CUDA-12.6.0
fails with:
attempt to concatenate a nil value
A second way to trigger the same issue is:
module purge
module load Triton/3.3.1-gfbf-2024a-CUDA-12.6.0
module unload CUDA/12.6.0
After unloading CUDA, the Triton modulefile is evaluated while CUDA_HOME is no longer set, which leads to the same nil concatenation error. I tested the same sequence on another system, where unloading CUDA after loading Triton did not trigger the failure. So this appears to depend on the Lmod version/configuration or site setup (not sure).
I also hit a more indirect/state-dependent version of this while installing Boltz-2/2.2.1-foss-2024a-CUDA-12.6.0. EasyBuild failed during the cleanup step:
/usr/share/lmod/lmod/libexec/lmod python unload Boltz-2/2.2.1-foss-2024a-CUDA-12.6.0
with the same error from the Triton modulefile. This was less straightforward to reproduce and seemed to depend on the Lmod module state/load order. In my case it appeared when running the installation through a wrapper that exposes the project tree through /readonly/....
This relates to the discussion in easybuilders/easybuild-easyconfigs#26403. It was suggested that a generic fix may belong in the framework, around ModuleGenerator.set_environment.
I think it would make sense for the Lua module generator to handle these references more safely, for example by generating guarded Lua code instead of direct os.getenv("CUDA_HOME") .. ... concatenation.
I am seeing an Lmod failure with generated Lua modulefiles when modextravars references an environment variable that is set by another module.
The concrete case is Triton/3.3.1-gfbf-2024a-CUDA-12.6.0, which generates lines like:
setenv("TRITON_CUOBJDUMP_PATH", os.getenv("CUDA_HOME") .. "/bin/cubjdump")
setenv("TRITON_LIBDEVICE_PATH", os.getenv("CUDA_HOME") .. "/nvvm/libdevice/libdevice.10.bc")
This works while
CUDA_HOMEis set by the CUDA module, but the generated Triton modulefile itself is fragile: evaluating it without CUDA_HOME already fails. For example:fails with:
A second way to trigger the same issue is:
After unloading CUDA, the Triton modulefile is evaluated while CUDA_HOME is no longer set, which leads to the same nil concatenation error. I tested the same sequence on another system, where unloading CUDA after loading Triton did not trigger the failure. So this appears to depend on the Lmod version/configuration or site setup (not sure).
I also hit a more indirect/state-dependent version of this while installing Boltz-2/2.2.1-foss-2024a-CUDA-12.6.0. EasyBuild failed during the cleanup step:
/usr/share/lmod/lmod/libexec/lmod python unload Boltz-2/2.2.1-foss-2024a-CUDA-12.6.0
with the same error from the Triton modulefile. This was less straightforward to reproduce and seemed to depend on the Lmod module state/load order. In my case it appeared when running the installation through a wrapper that exposes the project tree through
/readonly/....This relates to the discussion in easybuilders/easybuild-easyconfigs#26403. It was suggested that a generic fix may belong in the framework, around ModuleGenerator.set_environment.
I think it would make sense for the Lua module generator to handle these references more safely, for example by generating guarded Lua code instead of direct
os.getenv("CUDA_HOME") ..... concatenation.