drop load storm safe guard for Environment Modules v4.2.4+

[xdelaruelle]

Environment Modules v4+ safely handles automatic module load by not reloading already loaded module. Same goes when unloading module: already unloaded dependency will not be evaluated again.

As a result, no safe guard test is required and it should even be avoided to get the module dependency correctly tracked.

If module dependency declaration is skipped, no relation binds the loaded modules. Thus unloading the dependency will not lead to the auto unload of the dependent module. Without "is-loaded" safe guard, dependency is always declared and loaded environment is kept consistent by auto_handling mechanism [1]

A new ModuleTool property named "supports_safe_auto_load" is introduced. When enabled, module load safe guard code is not generated like if depends_on is enabled.

"supports_safe_auto_load" is enabled for EnviromentModules 4.2.4+. Prior v4 versions were not handling safely module load of module parent name if already loaded module were not corresponding to the default version.

[1] https://modules.readthedocs.io/en/latest/module.html#envvar-MODULES_AUTO_HANDLING

[boegel]

@xdelaruelle Thanks a lot for the PR!

Correct me if I'm wrong, but this will effectively also change the behavior of module files that were created by EasyBuild with Modules v4.2.4+, since unloading a module file will now also trigger an unload of the modules that got loaded as dependency.

That may surprise people, so I wonder if we should make this opt-in, rather than auto-enabling this based on the version of Modules...

[xdelaruelle]

@xdelaruelle Thanks a lot for the PR!

Correct me if I'm wrong, but this will effectively also change the behavior of module files that were created by EasyBuild with Modules v4.2.4+, since unloading a module file will now also trigger an unload of the modules that got loaded as dependency.

That may surprise people, so I wonder if we should make this opt-in, rather than auto-enabling this based on the version of Modules...

@boegel It will auto-unload dependency modules only if they are not needed by other loaded modules and if these dependency modules have been auto-loaded. So there is a change, but it should not disturb users as they have not explicitly asked for the dependency.

I would prefer to enable this by default rather making it an option to enable as with current load storm safe guard code users may end up with inconsistent environment:

With load storm safe guard (you can unload M4 and keep libtool, a dependent module, loaded):

$ ml M4 libtool
$ ml -M4
$ ml
Currently Loaded Modulefiles:
 1) libtool/2.4.7

Without load storm safe guard (dependent module is unloaded):

$ ml M4 libtool
$ ml -M4
Unloading M4/1.4.18
  Unloading dependent: libtool/2.4.7

[boegel]

@xdelaruelle There's a window of opportunity for "breaking" changes since we're working towards EasyBuild v5.0, so I propose we apply this change then (either in the 5.0.x branch where we're currently preparing EasyBuild v5.0, or in develop once it's clear that there won't be any further EasyBuild 4.x releases after EasyBuild v4.9.0).

[xdelaruelle]

@boegel I have just changed this pull request's target to 5.0.x and rebased it to this branch.

[xdelaruelle]

@boegel, @branfosj I have rebased this pull request on the current 5.0.x branch. Please let me know if something should be changed for this PR to get merged.

[boegel]

@xdelaruelle Another one that needs fixing of merge conflict that was introduced recently... (maybe we should sync up via Slack on these related PRs, to get them merged more smoothly...)

[boegel]

lgtm