Adapt similar loaded module detection code and add tests to check
behavior when the target of a virtual module is loaded as is and a
virtual module targeting it is loaded/unloaded/switched/etc.
Also set test cases on module mixing regular and virtual versions,
playing with short or full path name representation.
Update the content of the g_loadedModuleFiles cache array right after
loading or unloading a module. Helps subsequent actions to learn the
exact current state, especially in case of single command implying
multiple actions (switch or load/unload of multiple modules)
Multiple loaded virtual modules may target same file so handling of the
_LMFILES_ path variable is changed to a 'duplicates' mode to ensure a
file entry will always correspond to a module entry in LOADEDMODULES.
Adapt entry removal in _LMFILES_ variable to delete the entry at the
index corresponding to the index of the entry removed in LOADEDMODULES.
Add new test cases to check this duplicate mode entries in all situation
where _LMFILES_ content is involved.
Add in checkValidModule procedure a 'g_modfileValid' global array to
save validity check result of a modulefile at first query, then reuse
this cached result on subsequent queries on same modulefile.
Add 'findModulepathFromModulefile' procedure to get the modulepath
corresponding to a passed modulefile (or modulerc).
Adapt 'search' cmd when looking at module alias target, to correctly
handle virtual modules. Modulepath directory is retrieved, when detecting
a virtual module, from the modulerc file that has defined this virtual
module.
Introduce 'isModuleVirtual' procedure to detect a module is virtual
based on its name and modulefile. A module is stated virtual if its name
cannot be found at end of its modulefile name.
When looking at loaded modules during a 'list' command, treat
specifically virtual modules, almost like full path modules.
Tags on loaded virtual module are not search as once loaded we do not
know anymore from what modulepath directory the virtual module was
coming from.
So a relative file to source from a modulefile or modulerc, is relative
starting from the directory of the modulefile/modulerc sourcing it.
Add a specific case to treat empty file name by the way.
Now getAbsolutePath procedure, which make a path passed as argument an
absolute path, check the current path of the interpreted modulefile or
modulerc rather always taking the current path of the module command
execution.
So a modulefile or modulerc can use relative paths based on a
determistic way as it is now based on their location. Previously it was
not possible as relative paths were dependent of the location from where
the module command was executed.
If ModulesCurrentModulefile variable is not empty, getAbsolutePath nows
it is called during a modulefile/modulerc interpretation, so it takes
the directory name of this ModulesCurrentModulefile as current working
directory.
Refactor handling of the ModulesCurrentModulefile public global variable
to get same treatment like ModuleName with a push/pop mechanism.
Then call to the new pushModuleFile and popModuleFile procedures is
gathered in the execute-modulefile and execute-modulerc procedures to
push filename before interpretation and popping it when interpretation
is done.
Change is that ModulesCurrentModulefile is reset after interpretation,
so when this variable is queried in a master interpretation context it
is possible to know if some file is currently being interpreted or not
(value restored to the empty string).
Introduce the virtual module concept with the 'module-virtual'
modulefile command. This new command takes a module name as first
argument and a modulefile location as second argument.
A virtual module stands for this module name associated to a modulefile.
The modulefile is the script interpreted when loading or unloading the
virtual module which appears or can be found with its virtual name.
Like a module aliases, virtual modules are expected to be defined within
modulerc files (at whatever rc level). Virtual modules can be targeted
by aliases or symbolic versions. They also compete with aliases and
regular modules for the implicit default version of a module.
Multiple virtual modules may target the same modulefile, which can
distinguish between these various virtual names by use of the
"[module-info name]" command.
A virtual module cannot be loaded using a full path name (merge of its
module path and its module name) as this file does not exist.
Based on a proof of concept made by Bert Wesarg [1].
[1] https://github.com/bertwesarg/modules-tcl/commit/545e9f
When restoring an initial interpreter variable which was a list, issue
occured as the 'slave eval set' was given more than one value argument.
Passing values enclosed in a 'list' fixes the issue.
Improve non-regression tests to ensure expected handling will persist
over times.
Closes#145
Adapt version modulefile, which is deployed in versioning installation
mode, to re-initialize module command during its unload, to restore the
command of the previously loaded version.
Goes through a full re-initialization to overcome incompatible
definition of the module command between version 3 and 4.
This full re-initialization cannot be attempted on scripting shells,
like Perl or Python, as function re-definition is not a common practice
on these languages.
Introduce the '@VERSION@' pattern, combination of Modules release and
build information, for building files to install.
Still rely on @MODULES_RELEASE@ and @MODULES_BUILD@ when these
information are needed prior to ./configure call (dist-related stuff) or
are expected to change after ./configure call (modulecmd.tcl in
dev environment).
Adapt defined modulepaths in example testsuite configuration file
(modulerc and .modulespath) depending if versioning installation mode is
enabled or not.
Adapt the 'string contains' tests in ksh init script (used to setup
FPATH, PATH and MANPATH without duplicates) to correctly handle paths
containing '+' character, which is detected as a pattern-specific
character on the '=~' test condition previously used.
If --enable-versioning configure option is set, default modulepath option
is changed from '$prefix/modulefiles' to
'$baseprefix/$MODULE_VERSION/modulefiles'.
Adapt installation process to handle modulepath containing special '$'
character. Adapt also install testsuite to correctly check these
modulepaths containing variable references.
Produce environment variable set code for Tcl shell with value enclosed
in curly braces {} rather double-quote "". Curly braces are more
effective to protect value from interpretation, like if it contains a
dollar character.
When --enable-versioning is set at configure time, deploy the setup of
the MODULE_VERSION and MODULE_VERSION_STACK environment variables in
modulecmd.tcl and in a version-specific modulefile.
This version-specific modulefile is deployed in a @baseprefix@/versions
modulepath directory, which is also created specifically for versioning
installation mode.
MODULE_VERSION and MODULE_VERSION_STACK environment variables setup in
modulecmd.tcl is commented if versioning installation mode is not
enabled rather deleted to guaranty consistency across code coverage
tests (same code line numbering whatever the installation options set).
version-specific modulefile is a bit different than the one used before
<4.0 as now module version is initialized when loading this module by
calling the autoinit action on the modulecmd.tcl script.
These version-specific modulefiles enable to switch from one module
version to another but there is an incompatibility of initialization
between Modules 3.2 and Modules >=4. Switching from Modules 3.2 to
Modules >4 will be possible, but not going back from >4 to version 3.2.
Restore the ability of C-version to resolve environment variable
reference put in MODULEPATH elements. Path element is registered in
MODULEPATH variable with its variable references. When path entry is
used, variable references are solved to get real path.
Add a 'resolvStringWithEnv' procedure to handle resolution of
environment variable references set in string.
Re-enable non-regression tests of 95-version suite.
Add 'install-testsiteconfig' make target to setup a dummy siteconfig.tcl
file in install_etcdir. Link that to some of the travis checks to run
testsuite with an existing siteconfig.tcl
Define a global g_init_errreport flag to know within report or
reportErrorAndExit procedure if error reporting has been initialized or
not. If not yet initialized, call to output message is saved in a buffer
list.
A 'initErrorReport' procedure is added to switch 'g_init_errreport' flag
and output every messages saved in buffer list.
With this change, it is possible to use reportDebug, reportWarning,
reportErrorAndExit, etc procedures transparently without having to know
if error reporting has been enabled or not. The report procedures can
then be used in siteconfig.tcl extension without messing paging output.
Regarding reportDebug, g_init_errreport enables to know if call has to
be saved since if error report is not initialized, debug mode status is
not yet known.
Add the possibility to setup a site-specific configuration Tcl script
which will be sourced at the start of modulecmd.tcl. This site-specific
Tcl script enables to supersede global variable and procedure definition
made in modulecmd.tcl. This way local adaptations can be made without
editing the modulecmd.tcl script.
'--etcdir' configure option is added to specify the location of the
site-specific configuration script.
