--update-modules-tool-cache broken for Lmod

[klust]

The Lmod user cache update support in easybuild/tools/modules.py is broken in two ways:

• Line 1348: The Lmod user cache is not always in ~/.lmod.d/.cache. Since Lmod 8.7.12 it has moved to ~/.cache/lmod (see also the note at the bottom of the page https://lmod.readthedocs.io/en/latest/125_personal_spider_cache.html)
• Line 1426: On the two versions of Lmod I checked (8.3.1 which is pretty ancient but still the one used on LUMI and 8.7.19 which I compiled myself) the user cache file is no longer called moduleT.lua but spiderT.x86_64_Linux.lua, which is also present in a compiled version. The moduleT.lua file created by EasyBuild is ignored.

[boegel]

Thanks for the bug report @klust!

It's pretty clear that this option isn't commonly used...

[klust]

Any fix is not urgent for me. We use user caches and often Lmod fails to find a package after an install so I was checking if that option could solve our problems. But I already have a workaround in a hook: simply deleting the user cache files and the cache will be recreated when needed as the user uses Lmod commands.

I've tried to install some older versions of Lmod and it looks like the cache file has been named spiderT.x86_64_Linux.lua since version 7.0 and possibly earlier. I've so far failed to install even older versions and get them to work properly though.

[boegel]

Partial fix in #4402

[Flamefire]

4403 introduced --module-cache-suffix. You can set that to $(uname -m)_$(uname -s) and it should work.

If you use LMOD_SYSTEM_NAME it needs to be: .${LMOD_SYSTEM_NAME}_.$(uname -m)_$(uname -s)

Not sure if we also need the compiled version or if LMod compiles it automatically. We can also think about using the above values as defaults when ´--module-cache_suffixis unset, i.e.None` iff we can distinguish that from setting it to empty.