TACC
Modules not reloading on compiler swap if using partial version specifier
Describe the bug
Loading a new compiler does not reload dependent modules, if the dependent modules were specified with a partial version, like python/3 instead of python/3.9.12.
To Reproduce Given the following dummy tree:
└── linux-rocky8-x86_64
├── Core
│ └── gcc
│ ├── 1.2.3.lua
│ └── 2.3.4.lua
└── gcc
├── 1.2.3
│ └── python
│ └── 10.1.2.lua
└── 2.3.4
└── python
└── 10.1.2.lua
If I load gcc/1 then python/10, I get the following:
$ module --force purge
$ ml gcc/1
$ ml python/10
$ echo $PATH
/dummy/python-10.1.2-gcc-1.2.3/bin:/dummy/gcc-1.2.3/bin:[...]
So far everything is as expected: I have Python 10.1.2 "compiled" with gcc 1.2.3 in the PATH.
Now if I load gcc/2, I expect both gcc and Python to swap:
$ ml gcc/2
The following have been reloaded with a version change:
1) gcc/1.2.3 => gcc/2.3.4
$ echo $PATH
/dummy/gcc-2.3.4/bin:/dummy/python-10.1.2-gcc-1.2.3/bin:[...]
But only the gcc swapped. The Python is now the wrong one, compiled with gcc 1.2.3.
Starting again from scratch, if instead I specify python/10.1.2:
$ module --force purge
$ ml gcc/1
$ ml python/10.1.2
$ ml gcc/2
Due to MODULEPATH changes, the following have been reloaded:
1) python/10.1.2
The following have been reloaded with a version change:
1) gcc/1.2.3 => gcc/2.3.4
We get the Python module swap we expected.
The same thing happens if I use ml python with no version specifier; it seems that partial version specifiers are the issue.
In this dummy tree, both Pythons had the same version number, but the same thing happens if the Pythons share a major version, like 10.1.2 and 10.2.3.
GCC modulefile contents
-- -*- lua -*-
whatis([[Name : gcc]])
whatis([[Version : 2.3.4]])
help([[Dummy gcc]])
prepend_path("MODULEPATH", "/mnt/home/lgarrison/scc/lmod_reload/modules-min/linux-rocky8-x86_64/gcc/2.3.4")
prepend_path("PATH", "/dummy/gcc-2.3.4/bin", ":")
Expected behavior In a sequence like:
$ ml gcc/1
$ ml python/10
$ ml gcc/2
I expect Python/10 to be reloaded, such that the Python/10 under the gcc/2 hierarchy is the active module.
Desktop (please complete the following information):
- OS: Linux
- Linux distribution: Rocky 8
- Lmod Version: 8.7.13-21-g3eae2070 (GitHub master). Originally seen in a site-wide installation, version 8.6.5.
module --miniConfig output
$ module --miniConfig
Modules based on Lua: Version 8.7.13 (8.7.13-21-g3eae2070) 2022-09-14 12:56 -05:00
by Robert McLay [email protected]
Changes from Default Configuration
----------------------------------
Name Where Set Default Value
---- --------- ------- -----
LFS_VERSION D 1.6.3 1.8.0
LMOD_FAST_TCL_INTERP C yes no
LMOD_LD_LIBRARY_PATH E false /run/opengl-driver/lib
LMOD_PACKAGE_PATH D nil <empty>
LMOD_PAGER C less /usr/bin/less
LMOD_SYSTEM_DEFAULT_MODULES D __unknown__ <empty>
LMOD_TCLSH C tclsh /usr/bin/tclsh
MODULEPATH_ROOT E /mnt/home/lgarrison/scc/lmod_reload/install/modulefiles
PATH_TO_LUA C lua /mnt/home/lgarrison/scc/lmod_reload/install/lua/lua/bin/lua
Where Set -> D: default, E: environment, C: configuration
lmod_cfg: lmod_config.lua SitePkg: SitePackage StdPkg: StandardPackage
Other: Set somewhere outside of normal locations
Thanks for the bug report and testing your issue with the latest version of Lmod. As you may have surmised, the issue is related to the userName being an approximate value of the fullName but not quite. I was able to reproduce the issue and fix it for me. I didn't rebuilt your example module tree.
Please use the "testing" branch and see if it fixes it for you.
I confirm the testing branch fixes the issue. Thanks for fixing this so quickly!
Not for this. I'll merge the testing branch into the main branch on Monday Oct. 24. This will be version Lmod 8.7.14