1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
|
.. _require-via:
Require via
===========
As described in the :ref:`spider-sub-command` design document, a loaded module
that enables a modulepath is considered the *via* module of other loaded
modules whose modulefiles are stored in this modulepath.
This document is about considering a *via* module as a requirement for the
loaded module stored in the modulepath it enables. This means, as with other
kinds of requirements, that unloading a *via* module:
* raises an error if ``auto_handling`` is disabled, as a dependent module is
loaded
* automatically unloads all dependent modules if ``auto_handling`` is enabled
(*DepUn* mechanism)
* automatically reloads all dependent modules if ``auto_handling`` is enabled
and an alternative *via* module is loaded (*DepRe* mechanism)
This feature provides a *module hierarchy* mechanism.
It is controlled by the :mconfig:`require_via` configuration option, which is
disabled by default to maintain compatibility in Modules version 5 branch.
This option will be enabled by default when moving to Modules version 6.
Via module requirement
----------------------
When :mconfig:`require_via` is enabled, *via* module is considered a
requirement by loaded modules whose modulefiles are stored in this enabled
modulepath. The same properties as for requirements defined with
:mfcmd:`prereq` apply:
* active requirement if *via* module is loaded before its dependent
* if *via* module is loaded after its dependent, it is considered a *Non
Particular Order* (NPO) requirement: such requirement is inactive
* if several loaded modules enable the same modulepath, the one considered as
the *via* module depends on :mconfig:`unload_match_order` config option
A module enabling an already enabled modulepath is not considered a via
module. In this situation a loaded module whose modulefile is stored in this
modulepath do not have a dependency on any modulepath-enabling loaded modules.
Since modulepath have already been enabled before other modules are loaded.
Same behavior is observed on Lmod.
Modulepath enabling may be expressed with reference to external environment
variables. Modulepath resolution is thus dynamic.
*Via* module requirement adds to the other kinds of requirements which are
checked to guarantee the consistency of the loaded environment. Depending on
:mconfig:`auto_handling` value, load or unload operations that impact
dependency consistency may lead to:
* an error if ``auto_handling`` is disabled
* automatic dependent module unload or reload if ``auto_handling`` is enabled
Dependent Reload mechanism update
---------------------------------
Dependent modules of a *via* module are targeted by the Dependent Reload
(DepRe) mechanism if *via* module is swapped or unloaded by Conflict Unload
(ConUn) mechanism.
As introduced with the ConUn mechanism, a test is made prior reloading each
DepRe module to check if it is loadable. If test determines module is not
able to reload, the reload is skipped and the module is considered a Dependent
Unload (DepUn) module.
This test checks no conflicting module are loaded and requirements are loaded.
A new check is added for all DepRe modules attempting to reload: it should be
available in enabled modulepaths.
Either the modulepath where module is stored is still enabled or module is
found in enabled modulepaths.
This availability new check is not linked to the ``require_via`` configuration
option. It is performed even when option is disabled. What is linked to this
option is to include the dependent of a *via* module in the DepRe mechanism.
*NOTE*: The availability of used variants is not checked by this mechanism.
Thus if modulefile is found but it does not contain anymore the used variant,
a DepRe error is obtained.
*FUTURE*: DepRe module reload may be attempted whatever the conditions and in
case of error, this evaluation is silenced if error is of following kind:
conflict present, requirement missing, module not available, variant not
available. Such behavior would help if variant is not available anymore or
if module in new modulepath does not express the same conflicts or
requirements.
In case of modulepath change and module reload, tags defined in the disabled
modulepath does not apply anymore to the reloading module. Tags defined in new
modulepath does. Extra tags are re-applied to the reloading module.
Unused modulepath
-----------------
When modulepath is unused from the command-line, nothing is unloaded as
dependency is based on *via* module. If *via* module is unloaded afterward,
dependency link is still active if ``require_via`` is enabled.
*CORNER CASE*: There is an exception if module is virtual since its modulepath
cannot be guessed for sure, thus the dependency link cannot be maintained with
such modules.
*FUTURE*: storing modulepath of loaded modulefiles in environment would help
to know for sure the modulepath where the virtual module is stored even if the
modulepath is no longer enabled in environment.
*NOTE*: When modulepath is unused from the command-line, Lmod inactivates
modules stored in this modulepath. If modulepath is unused externally and the
*via* module is then unloaded, Lmod still inactivates modules stored in this
modulepath.
*CORNER CASE*: if modulepath is unused, no *via* module loaded and modules
stored in this path are loaded, loading the *via* module for this part does
not trigger a reload of modules stored in this path. It is not known that the
module to load is the *via* module, thus modules stored in this path are not
set to reload prior this module load.
Several modules enabling same modulepath
----------------------------------------
When same modulepath is enabled by multiple modules, the *via* module is
determined, like other kinds of requirements, based on
:mconfig:`unload_match_order` configuration option:
* when it equals ``returnlast``: lastly loaded module before dependent is the
*via* module
* when it equals ``returnfirst``: firstly loaded module before dependent is
the *via* module
Any module enabling modulepath but loaded after dependent is considered a *Non
Particular Order* dependency. It is taken into account if regular *via* module
loaded before dependent is unloaded. In this case, the dependent is reloaded
to adopt the *via* module loaded afterward as its new dependency.
When several modules enabling same modulepath are loaded before the dependent,
unloading the one considered the *via* module currently unloads the dependent.
The other potential *via* modules are not taken into account, unless one is
loaded after the dependent module. Same behavior is observed with other kinds
of requirements.
*FUTURE*: take into account alternative *via* module loaded before dependent
when main one is unloaded, to reload dependent and bind it to the new *via*
module (lastly or firstly loaded one, depending on ``unload_match_order``).
.. vim:set tabstop=2 shiftwidth=2 expandtab autoindent:
|
