module unload performs an unloading of dependent module

[Laurent-Besson]

Describe the bug

I have a module "A" and a module "B"

In Modulefile "B", I write

`#%Module

module load A `

Under my shell, I do:

ml A ml B ml -A

And I see it does unload Module "B". My term shows:

' Unloading A Unloading dependent: B '

Is it expected ? This feature is not so obvious to me.

The other way round works fine and is correct from my point of view:: If I unload "B", then it should unload "A" (if no other packages need it). But when I unload "A", why should the tool unload also "B" ?

I'm running Module 5.5.0 under RHEL7/8

BR, Laurent.

[RobyB]

I was about to write a message about exactly the same "issue". Reading documentation i found that there is a tag that should cover this, but i was not able to use it correctly. Involved tags, if i understand correctly, are "--no-auto" and "--auto".

Probably a simple example on how to use this tag would clarify this issue.

Roberto On 16 Jun 2025 at 14:04 +0200, Laurent Besson @.***>, wrote:

Laurent-Besson created an issue (envmodules/modules#578) Describe the bug I have a module "A" and a module "B" In Modulefile "B", I write #%Module module load A Under my shell, I do: ml A ml B ml -A And I see it does unload Module "B". My term shows: ' Unloading A Unloading dependent: B ' Is it expected ? This feature is not so obvious to me. The other way round works fine and is correct from my point of view:: If I unload "B", then it should unload "A" (if no other packages need it). But when I unload "A", why should the tool unload also "B" ? I'm running Module 5.5.0 under RHEL7/8 BR, Laurent. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[xdelaruelle]

The rationale is that if B contains module load A it means that B needs A to work correctly. This is the definition of a requirement. Thus if A is unloaded, B cannot work anymore so for the sake of consistency, dependent module B is auto unloaded.

If you do not want module load A (or module unload) commands to be treated as requirement expressions, you have two options:

• Disable the implicit_requirement configuration option. This turns off this requirement mechanism globally.

• Use the --not-req option with the module command —e.g., module load --not-req A. This disables the requirement mechanism only for that specific command.

Best regards, Xavier

[RobyB]

Thx for the fast answer. Personally i perfectly understand the rationale behind this behaviour.

The "problem" with this reasoning is the following: Sometimes module B really needs module A to be working correctly so this is behaviour is perfectly fine. Sometimes a module just loads two (or more) tools that can exist independently. This second case, at least for me, is very often the case as i have setup modulefiles in such a way that a user just needs to load a single modulefile for the project he is working on and this modulefile will load all needed tools with default versions for that project. If now a user wants to just change a single tool version this breaks everything because when he unloads module A to replace it with another version (of the same tool) both modules A and B will unload and when he loads the new version of tool A he will no longer have tool B loaded.

Of course one could use module switch command for that, but most users don't know all the details of modules and just use load/unload commands.

Therefore i think one should/could separate the two behaviours in a "simple" way.

If module A requires module B to work you should use the prereq (and variants) statement in the modulefile If instead module A and B. are just loaded from within the modulefile one should use the module load command.

This would clearly separate the two usages and leave all the "complexity" to people actually writing modulefiles and would keep things "simple and working as expected" to normal users.

Of course this issue can be handled as you suggest (with the --not-req) switch inside the modulefile, but it seems less logical to me. Maybe another option could be to have the --not-req option on by default, and introduce a module load --req B command that would be equivalent to prereq B

Roberto

Sent with Spark On 16 Jun 2025 at 21:04 +0200, Xavier Delaruelle @.***>, wrote:

xdelaruelle left a comment (envmodules/modules#578) The rationale is that if B contains module load A it means that B needs A to work correctly. This is the definition of a requirement. Thus if A is unloaded, B cannot work anymore so for the sake of consistency, dependent module B is auto unloaded. If you do not want module load A (or module unload) commands to be treated as requirement expressions, you have two options:

• > Disable the implicit_requirement configuration option. This turns off this requirement mechanism globally. • > Use the --not-req option with the module command —e.g., module load --not-req A. This disables the requirement mechanism only for that specific command.

Best regards, Xavier — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

[xdelaruelle]

Along the time the requirement definition moved from prereq A to module load A as it provided a convenient dependency auto-load mechanism. This is why module load command in modulefile is considered by default a requirement definition.

If you have properly organized your modulefiles and all the requirement definition rely on prereq command, you can choose to disable the implicit_requirement configuration option:

module config implicit_requirement 0

This way all the module load/unload/switch in modulefiles will not be considered an implicit requirement definition.

This module config command can be set in the initrc file to apply to all users.

[xdelaruelle]

@Laurent-Besson or @RobyB any additional feedback on the proposed solution?

[RobyB]

Absolutely fine for me.

Roberto On 30 Jun 2025 at 05:41 +0200, Xavier Delaruelle @.***>, wrote:

xdelaruelle left a comment (envmodules/modules#578) @Laurent-Besson or @RobyB any additional feedback on the proposed solution? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

[Laurent-Besson]

After some thinking, I understand the rationale behind the default mechanism and agree with it. Let's stick to what has been implemented so far and, eventually, use implicit requirement if really needed.

Xavier, thanks for the followup :)