Conflict Unload: new mechanism to unload conflicts when loading a module

[xdelaruelle]

Following this discussion on the mailing-list.

Automatically unloading modules that conflict with one asked to be loaded seems to be an interesting feature. Actually, this is an additional automated mechanism that improves the existing automated handling mechanism set.

This should apply to any load evaluation (raised by a load or a switch sub-commands).

Still need to determine the complete scope of these conflicting modules automatic unload.

[xdelaruelle]

Additionnal details on this message

[reinh-bader]

I do suggest enabling this behaviour with an additional switch in an interactive environment. It is probably OK to make this behaviour default if the "module load" is issued inside a module file.

Regards
Reinhold

[wenzler]

I still see the collision handling as incompatible with modules3 crude way (as it was present in 4.1?)
This must for sure not be a default behaviour in any way to allow some compatibility to existing module pools.

[RobyB]

Trying to make sure modules handles correctly all possible conflicts in an "intelligent" way seems the wrong approach to me. How often does it happen that from a shell you'll have to switch module configuration files? It seems an overkill to me which will introduce lots of work on the developer side and not so a big reward at the end. Would be much better to have (and probably there is already) a clean way to uninstall all modules loaded under a certain hierarchy and then reload the new needed ones! Like if you have Top/A/A.2 Top A/A.7 Top/B Top/C/C.1/C.1.2 Top/C/C.1/C.1.3 . Suppose you have loaded Top/C/C.1/C.1.2 and need to switch to Top/C/C.1/C.1.3 it would be enough (for most cases) to be able to issue a module unload C (that unloads all modules in that tree respecting dependencies that are inside that tree) followed by a module load Top/C/C.1/C.1.3 Of course the real hierarchy might be much more complicated, but you get the idea. It is to the developer of the modulefiles to try to have as few interdependencies as possible (which is not always possible but...) From my experience this covers 99.99% of use cases of users using modules. Just my 2cents. Roberto

…

On Tue, Mar 19, 2019 at 6:32 PM Xavier Delaruelle ***@***.***> wrote: Following this discussion <https://sourceforge.net/p/modules/mailman/message/36613635/> on the mailing-list. Automatically unloading modules that conflict with one asked to be loaded seems to be an interesting feature. Actually, this is an additional automated mechanism that improves the existing automated handling mechanism set. This should apply to any load evaluation (raised by a load or a switch sub-commands). Still need to determine the complete scope of these conflicting modules automatic unload. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#242>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEifO1p6DyhQ_jI1U5iP7xxwlyJaUWQpks5vYR80gaJpZM4b8tzY> .

[xdelaruelle]

@wenzler Conflict Unload will be part of the automated module handling mode which has been introduced in version 4.2 of Modules and which is off by default, and will stay off by default for the duration of Modules 4.

@RobyB That is a nice developer challenge, but of course it should not impact modulefile developers, just the module command developer. Regarding the example you provide, the idea is to enable users to just module load Top/C/C.1/C.1.3 which will automatically unload Top/C/C.1/C.1.2.