Evaluation

Current solution

The initial request was to enable users to set-up working environment easily providing possibility of choosing:

compiler (and its version)
DataDictionary version
Access Layer version
a versions of other of libraries used by WPCD developers

As a result of discussions two steps (wpcdenv/imasenv) schema was introduced, to provide a freedom of choice and not to make module name too complicated (like imasenv/3.24.0/intel/18.0/ual/4.1.5/wpcdenv/4.0)

wpcdenv (e.g. wpcdenv/intel/18.0/1.1) sets compiler, its versions and loads all DD/IMAS independent libraries (e.g. blitz, lapack, xmllib)
imasenv (e.g. imasenv/3.24.0/ual/4.1.5/1.1) sets IMAS for given DD version and loads all DD/IMAS dependent libraries (e.g. ggd, amns)

Lesson learned

After one year, since it's initial design, I decided to evaluate wpcdenv/imasenv scenario. Outcome of evaluation:

in most cases users specify only "module load imasenv" or "module load imasenv/<dd-ver> "
UAL is a "yet another library" that don't has to be set separately ("ual/<al-version>" part of schema)
users don't take into account *AL version* and other libs version... and use defaults
users don't take into account compiler version... and use default one
there is a need to couple imasenv with particular wpcdenv version:
- currently imasenv loads default wpcdenv
- all imasenv libraries can be not compatible with other wpcdenv version as being used during compilation
- loading manually wpcdenv by user and than imasenv can result in inconsistent environment
The number of modules is growing very fast (see "module avail imasenv") - it is harder and harder to find a proper version

Thus, there is a need of simplification of described mechanism and to provide a proper lifecycle !

Simplification of wpcdenv/imasenv schema

Propositions to simplify mechanism for setting working environment base on initial David C. suggestions (yes, Dave, I should follow your hints):

to remove "ual/<al-version>" part of imasenv module name
to remove "<compiler-version>" part of wpcdenv module name

to combine wpcdenv and imasenv within one module

imasenv/<dd-ver>/<compiler_vendor>/<compiler_version>/<library-set-ver>
e.g.:
imasenv/3.24.0/intel/17.0/1.0.2

Justification:

Proposed schema is simplification (from users point of view) of existing mechanism
(already mentioned) no need to handle AL differently than other libraries
It solves problem of coupling libraries and its dependencies used at compilation time (aka a correct wpcdenv for given imasenv)
The change will be transparent for the users that loads defaults calling "module load imasenv[/dd-ver]"

Lifecycle

Defaults

Please note that module system allows to provide defaults on every level of module structure - a "tail" of module name can be skipped to use default versions.

Taking imasenv as an example, following calls loads the same module :

module load imasenv
module load imasenv/3.24.0
module load imasenv/3.24.0/intel
module load imasenv/3.24.0/intel/17.0
module load imasenv/3.24.0/intel/17.0/1.0.2

under assumptions:

3.24.0 is a default DD version
intel is default compiler
17.0 is default compiler version
1.0.2 is default set of libraries compiled by intel

"WPCD products"

ETS workflow is the most complex product being developed by WPCD, however WPCD activity is not limited to ETS development, so this document will refer to "WPCD products" keeping in mind that in most cases it is synonym of "ERTS workflow"

Tagged version

Tagged version of module, used by some tagged version(s) of CD product(s)
Must be well tested and stable
This version is intended to use mainly by users , to provide them stable environment for running CD product(s)
The chosen tagged version (in most cases the latest one) is set as default one

Release candidate (RC)

A candidate for a next tagged version
Provides a common, unified environment for developers working on next version of given CD product
A RC version should be stable, however it would be changed quite often (patches, new functionality of libraries) so it may happen that RC version will have some issues
Once WPCD confirms that its product works fine, RC is tagged

Alpha version

A candidate for a next tagged version
Introduced to make sure that update/change requested by developer(s) is "safe" and will not brake environment (used by large group of developers)
Used by a limited group of testers (usually by person who request change plus one/two other testers)
Used for limited amount of time (omne, two days)
If tests are passed, changes are introduced to RC:
- patches automatically
- library updates (that may change APIs) after confirmation coming from WPCD
BTW: Alpha version is an equivalent of "module load imasenv/x.y.z/rc; module switch tested-lib/tested-ver"