Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Qu re auto-handling on switch #293

Open
payerle opened this issue Sep 19, 2019 · 1 comment
Open

Qu re auto-handling on switch #293

payerle opened this issue Sep 19, 2019 · 1 comment

Comments

@payerle
Copy link
Contributor

payerle commented Sep 19, 2019

I just recently discovered the auto-handling feature added to 4.2, and find it very interesting. Thank you for adding that, it was on my "wish-list"

But I have a question regarding its implementation, particularly as relates to the switch subcommand. In particular, if during a "module switch" of some module modA another module modB is found that has a prereq on modA, it is unloaded before the old modA is unloaded, and then reloaded after the new modA is loaded. However, it appears to me that when reloading
modB, what is attempted to be reloaded is the fully qualified module name that was actually loaded, and not the "alias" for the module that was actually entered by the user.

Concrete example: Consider packages modA and modB, each having versions 1 and 2, with
modB/1 having a prereq on modA/1, and modB/2 having a prereq on modA/2.
The .modulerc for modB will default to modB/1 if modA/1 was previously loaded, and modB/2
otherwise.

The assume the user does the sequence
(1) module load modA/1
(2) module load modB
(3) module switch modA/2

In the module load in (2), because modA/1 was previously loaded, the .modulerc for modB will cause modB/1 to be loaded.

In (3), after modB and modA are unloaded, modA/2 is loaded, and then *** modB/1 *** will attempt to be reloaded. This will fail as modB/1 has a prereq on a specific version of modA (namely, modA/1).

I would expect the above behavior if the user in step (2) issued "module load modB/1" instead
of "module load modB", since in that case they requested a specific version of modB.
But if the user (as shown above) did not specify a version for modB in step (2), then I would
have expected the reload from the module switch to be for "modB", not "modB/1". In which
case, the modB .modulerc, seeing modA/2 is loaded, would default to modB/2.

It looks to me like this should be technically feasible to implement (the MODULES_LMALTNAME env variable seems to contain the required information to determine what the user requested when modB/1 was loaded).

@xdelaruelle
Copy link
Member

The current approach is to reload the exact same dependent modules to avoid any surprise. However I foresee your use case and an alternative behavior may be proposed to perform these reloads based on module specified names not loaded names.

There should be an additional information saved in the environment to catch name specified by user. MODULES_LMALTNAME environment variable holds all the alternative names of loaded environment, not the name typed by user to load the module.

But prior such work, the remaining auto_handling mechanisms should be developed to ensure such an alternative behavior is compatible with all mechanisms. Especially the Conflict Unload and Loaded Reload mechanisms.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants