Robot does not recognize installed modulerc aliases with hierarchical MNS

[vanzod]

As reported in easybuilders/easybuild-easyblocks#1534, the use of short names in a .modulerc wrapper file (introduced with easybuilders/easybuild-easyblocks#1535) prevents robot to correctly identify installed module wrappers when a hierarchical MNS is used. This forces EB to re-install the wrapper every time it is needed as a dependency. The installation will then fail since the .modulerc file cannot be replaced without an explicit --force flag:

 == FAILED: Installation ended unsuccessfully (build directory: /mnt/ramdisk/Java/1.8/dummy-dummy): build failed (first 300 chars): Found existing file at /opt/easybuild/modules/all/Core/Java/.modulerc.lua, not overwriting without --force

[boegel]

The actual problem here is that we check whether modules already exist based on the full module name, which is for example Core/Java/1.8 rather than the short/user-facing module name Java/1.8.

The reason for this is that for non-Core modules may not be visible yet, unless one or more modules that open the part of the module tree where that module lives is loaded.

Using the full module name, we can always check whether a module file already exists by simply adding the top of the module tree to $MODULEPATH.
But this only works for module files that actually exist, not for wrappers defined in a .modulerc... That's the issue we're hitting now.

The fix that was done in easybuilders/easybuild-easyblocks#1535 is correct, the wrapper should be defined for the short module name, i.e. Java/1.8 is a wrapper/alias/symbolic version for Java/1.8.0_181 (not for Core/Java/1.8.0_181).

I've been thinking what the proper fix for this would be...

This probably involves enhancing/fixing the exist function in the Modules implementation, which now already checks with ml avail first, and falls back to using ml show (which works for hidden modules for example).
I see two options:

• let exist also explicitly check whether the specified module exists as a wrapper, by looking for a .modulerc where the wrapper is defined; one problem here is that both Tcl & Lua syntax need to be taken into account
• also check with ml spider as a fallback, but that's also not trivial since we may be picking up modules (& wrappers) in other locations...

cc @zao

[vanzod]

I think that checking for a .modulerc or .modulerc.lua is the best strategy. It may be worth considering adding a comment at the beginning of the wrapper files that says something like "Generated by EasyBuild" in order to avoid parsing custom .modulerc files.