Modules 3.1.3 and beyond?

[R.K. O. Ph.D. <rk...@ow...>]

Hello Modules list:

I've released version 3.1.3, which has the following changes (the biggest
being the addition of about 100 tests & quoting the environment variable
contents, plus some significant bug fixes).  I think this release is
pretty solid.

Modules 3.1.3
Wed Jul 11 14:30:53 PDT 2001		R.K. Owen (rk...@ow...)
	* Added module-cvs modulefile for easy CVS/ftp access to the
	  modules CVS repository.
	* Added README.perl describing Ron Isaacson's Env::Modulecmd
	  perl module (Ron...@mo...).
	* Added document file INSTALL.RH7x which explains how to set up
	  an modules environment for all users through the system shell
	  files.  Is specific to Linux/RedHat 7.x, but is of general
	  applicability.
	* Added further tests for modulefile "module use dir_path"
	* Fixed bug of unloading a modulefile with a "module use dir_path"
	* Environment variable contents are now quoted to preserve
	  any embedded environment variables. (Needed for versioning)
	* Added over 50 tests specific to module versioning, and testing
	  xgetenv.
	* Fixed the unsetenv on unload function, the feature added in 3.0.6-rko
	  was supposed to set the env.var. to the optional third argument.
	  This was to allow old env.var. values to be recovered by unraveling
	  a stack set in an other env.var.  Added tests for this feature.
	  This is used by the version modulefile.
	* Fixed and updated the version modulefile to allow stacked
	  versions to be removed the stack.
	* Removed an annoying spurious stderr newline.
	
Modules 3.1.2
Fri Jun  8 23:12:24 PDT 2001		R.K. Owen (rk...@ow...)
	* Fixed the "module use --append" feature, and fixed the tests
	  for "module use", "module use --append", and "module unuse".
	* Changed the global variable names (flags,current_module) to
	  (g_flags, g_current_module) to identify their ubiquity in the
	  module source.

------------------------------------------------------------------------
The purpose of this latest version, was to fix all the known bugs, and
to add many more tests to try all the various features, and to get the
module versioning working as it was meant to.  The earlier versions
only tended to work ``one way''.  It wasn't possible to unravel the
stacked versions.  This required that the modulecmd output single quote
the environment variable contents to unexpand any embedded environment
variables on an eval.

Now it comes to the heart of the matter.  There have been some requests
to fix modules to handle deep modulefile directories with regards
to version files, etc..  I have attempted to do so, but as I have
mentioned in previous emails, the current modules package assumes a
shallow modulefile directory.  This is manifest in the module-version
command.

I don't use module-version myself except indirectly via the
set ModulesVersion command in .version files.
The "set ModulesVersion x.x.x" does "module-version x.x.x default"
under the covers.

The problems, I see, are when it's used like
	module-version xxx/1.0 foo
which implicitly assumes a single directory level.

I propose that in the xxx/.modulerc file
	module-version /1.0 cur stable default
	module-version  2.0 dev unstable

such module-version commands only apply within the directory they are defined.

The syntax would be
	module-version [/]xxx name1 [name2 ...]
where name=default has it's usual special properties.

If the directory structure is
	xxx/
	.modulerc :
	module-version dir1 cur stable default
	module-version dir2 dev unstable
		dir1/
		.modulerc :
		module-version sub1 cur stable default
		module-version sub2 dev unstable
			sub1/
			.modulerc :
			module-version 1.0 cur stable default
			module-version 1.1 dev unstable
				1.0
				1.1
			sub2/
			.modulerc :
			module-version 2.0 cur stable default
			module-version 2.1 dev unstable
				2.0
				2.1
		dir2/
		.modulerc :
		module-version sub1 cur stable default
		module-version sub2 dev unstable
		... same as above

with such a structure then the following module commands would
be decipherable as:
	module load xxx			-> loads xxx/dir1/sub1/1.0
	module load xxx/dev/dev/dev	-> loads xxx/dir2/sub2/2.1
	module load xxx/cur/dev		-> loads xxx/dir1/sub2/2.0

In order to handle deep modulefile directories, the module-version
command must be modified as I have described above, and its previous
acceptable use
	module-version xxx/1.0 foo
would now be unacceptable and would cause an error. (Or I might try to
allow it for shallow directories.)

However, to accomplish these changes, it will require rewriting a
good portion of the locating module parts.  And while I'm at it, I
intend to make the code more object oriented to make the code easier
to deal with.  I think most everyone who has looked at the sources
will agree that there are too many global variables, side effects,
and special cases embedded in the code making the simplest of changes
a potential catastrophe waiting to be triggered later.  A potential
windfall may be the ability to use other embedded interpretors
besides Tcl (just a thought).

Therefore, I will start a new development line 3.2.x, and keep the
the old line 3.1.x going for people that require the traditional style.
The only changes to 3.1.x will be bug fixes, scripts, and tools that
are equally applicable to 3.2.x.

Any comments and discussion are welcome.

Regards
	R.K.
+-----------------------+----------------------------------+
| R.K.Owen,PhD          | rk...@ow...   (408)377-5373 |
| KooZ Software         |                                  |
| NERSC/LBNL            | rk...@ne...   (510)486-7556 |
+-----------------------+----------------------------------+
The newest modules sources can be found at

Primary-site:   ftp://modules.sourceforge.net/pub/modules
(there right now.)

Alternate-site: ftp://sunsite.unc.edu/pub/Linux/utils/shell/
(It may be a few days before they get moved from the incoming to
the above sunsite directory.)