When updating modulepath, reloading a sticky module (dependent of the via module) may end up not finding this sticky module in the new modulepath. This unavailability should abort the whole operation (as it should not be possible to escape a sticky module without forcing things, and not at all in case of super-sticky module).
Currently on 5.6.0, such dependent reload issue is only treated as a warning. It should be an error that abort the whole operation.
$ cat /path/to/modulefiles/foo/1
#%Module
module use /path/to/modulefiles.2
$ cat /path/to/modulefiles/foo/2
#%Module
module use /path/to/modulefiles.3
$ cat /path/to/modulefiles.2/bar/.modulerc
#%Module
module-tag sticky bar
$ cat /path/to/modulefiles.2/bar/1
#%Module
$ ml config require_via 1
$ ml foo/1 bar
$ ml
Currently Loaded Modulefiles:
1) foo/1 2) bar/1 <S>
$ module switch foo/2
Switching from foo/1 to foo/2
ERROR: Unable to locate a modulefile for 'bar/1'
WARNING: Reload of dependent bar/1 failed
Unloading dependent: bar/1
$ ml
Currently Loaded Modulefiles:
1) foo/2
When updating modulepath, reloading a sticky module (dependent of the via module) may end up not finding this sticky module in the new modulepath. This unavailability should abort the whole operation (as it should not be possible to escape a sticky module without forcing things, and not at all in case of super-sticky module).
Currently on 5.6.0, such dependent reload issue is only treated as a warning. It should be an error that abort the whole operation.