You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
The text was updated successfully, but these errors were encountered:
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.
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).
The text was updated successfully, but these errors were encountered: