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).
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).