|
From: Xavier D. <xav...@gm...> - 2024-10-30 03:27:42
|
Here I am burying a quite old thread, but the use case that is
described here will be solved with the conflict_unload mechanism
(available in upcoming version 5.5).
Some example:
$ module load foo/1
Loading foo/1
Loading requirement: qux/1 bar/1
$ module load foo/2
Loading foo/2
ERROR: Module cannot be loaded due to a conflict.
HINT: Might try "module unload foo/1" first.
$ module config conflict_unload 1
$ module load foo/2
Loading foo/2
Unloading conflict: foo/1
Regards,
Xavier
Le dim. 20 janv. 2019 à 16:18, Scott Hampton <sha...@nd...> a écrit :
>
> Hi Xavier,
>
> As an example, I have 2 versions of the Intel compiler along with two versions of OpenMPI for each version of the compiler. Given similar commands in all module files, I get the desired outcome:
>
> intel/17.1:
> module unload intel
> ...
>
> openmpi/2.1.1:
> module unload openmpi
> module load intel/17.1
> ...
>
> After loading any module, attempts to load another version fail. This works for all combinations of the two mentioned modules, regardless of the order in which modules are loaded (compiler/mpi).
>
> Is there a better way to do this?
>
> Thanks,
>
> Scott
>
>
>
>
> On Sat, Jan 19, 2019 at 8:29 AM Xavier Delaruelle <xav...@gm...> wrote:
>>
>> Looking deeper at your issue, I do not understand how you fixed it because for me there is a regression with v4.2.
>>
>> Due to the conflict consistency, if a `foo` module is loaded the load of any other version of the foo module will be denied due to the reflexive conflict it has registered with the `module unload foo` command. So for instance if any `foo` modules hold a `module unload foo` command, if `foo/1` is loaded, the load tentative of `load/2` will fail without any evaluation of the `foo/2` modulefile.
>>
>> I have just made a fix to restore the expected behavior: in case a conflict constraint toward a modulefile is set by an already loaded modulefile, loading the conflicting modulefile will lead to a load evaluation attempt in order for this modulefile to get the chance to solve the constraint violation. If at the end of the load evaluation, the conflict has not been solved, modulefile load will be discarded.
>>
>> This fix will be shipped in next bugfix release (v4.2.2).
>>
>> Regards,
>> Xavier
>>
>> [1] https://github.com/cea-hpc/modules/issues/216
>>
>> Le lun. 7 janv. 2019 à 17:12, Scott Hampton <sha...@nd...> a écrit :
>>>
>>> Thank you for the feedback. I was able to get the functionality I wanted using something similar to the following. Given that FOO depends on GCC,
>>>
>>> # FOO module file
>>> unload FOO
>>> load gcc
>>>
>>> # gcc module file
>>> unload gcc
>>>
>>> Now, only 1 copy of either FOO or GCC can be loaded at the same time. The mistake I was making was to try and unload gcc, then immediately load it within the FOO module file.
>>>
>>> Thanks, again.
>>>
>>> Scott
>>>
>>> On Fri, Jan 4, 2019 at 10:18 AM Xavier Delaruelle <xav...@gm...> wrote:
>>>>
>>>> Hello Scott,
>>>>
>>>> With the current 4.2 version you can either force the load of the new module, which will unload the previous one if the new one contains a "module unload foo" command:
>>>>
>>>> $ module load foo/2
>>>> Loading foo/2
>>>> ERROR: foo/2 cannot be loaded due to a conflict.
>>>> HINT: Might try "module unload foo/1" first.
>>>> $ module load foo/2 --force
>>>> Loading foo/2
>>>> WARNING: foo/2 conflicts with foo/1
>>>> Unloading conflict: foo/1
>>>> $ module list
>>>> Currently Loaded Modulefiles:
>>>> 1) foo/2
>>>>
>>>> Or use the 'switch' command to load the new module, which will unload the previous one in any cases before loading the new one:
>>>>
>>>> $ module list
>>>> Currently Loaded Modulefiles:
>>>> 1) foo/1
>>>> $ module switch foo/2
>>>> $ module list
>>>> Currently Loaded Modulefiles:
>>>> 1) foo/2
>>>>
>>>> In a future release, an additional automated module handling mechanism will be introduced called "Conflict Unload". With that, conflict declared from/toward a loading module will be solved by unloading conflicting loaded modules (still need to think to what extend it should unload already loaded modules). Another feature that will be introduced is a dependency look ahead to solve them prior effectively evaluating modulefiles. With that it may also be possible to detect a "module unload foo" command thus let the load of this module happen even if a conflict is declared on it by another "foo" modulefile already loaded.
>>>>
>>>> Regards,
>>>> Xavier
>>>>
>>>> Le jeu. 3 janv. 2019 à 21:48, Scott Hampton <sha...@nd...> a écrit :
>>>>>
>>>>> Prior to 4.2.1, we would add code to our module files that would only allow you to have one version of a module loaded at a time by starting out the module file with either a conflict or an unload command. For example every version of module "foo" would have either:
>>>>>
>>>>> module unload foo
>>>>>
>>>>> or
>>>>>
>>>>> conflict foo
>>>>>
>>>>> at the beginning. Thus, if you had module foo/1 loaded and tried to load version foo/2, it would either silently make the switch or complain.
>>>>>
>>>>> Now that both of these commands are persistent, neither of these generalizations work. I realize that I could say:
>>>>>
>>>>> conflict foo/1 foo/2 .. foo/x
>>>>>
>>>>> but that seems untenable for a couple of hundred module files, dozens of which are changing throughout the year. Any thoughts on alternate solutions or are we destined to abandon this feature?
>>>>>
>>>>> Thanks.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Modules-interest mailing list
>>>>> Mod...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/modules-interest
>>>>
>>>> _______________________________________________
>>>> Modules-interest mailing list
>>>> Mod...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/modules-interest
>>>
>>> _______________________________________________
>>> Modules-interest mailing list
>>> Mod...@li...
>>> https://lists.sourceforge.net/lists/listinfo/modules-interest
>>
>> _______________________________________________
>> Modules-interest mailing list
>> Mod...@li...
>> https://lists.sourceforge.net/lists/listinfo/modules-interest
>
> _______________________________________________
> Modules-interest mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modules-interest
|
