RKO modules

[David C. M. <Dav...@lm...>]

"R.K. Owen Ph.D." wrote:

> Hello one & all:
> Being totally unaware that there is any organized effort to develop the modules
> software.  I've posted the following to the comp.os.linux.announce (c.o.l.a)
> news group announcing the availability of modules for linux.
>
> All I know is that I had to overcome several major hurdles to get
> modules working on Linux (or any other system), especially starting
> with the 3.0beta sources, which had the features I wanted.  I checked
> with the www.modules.org webmaster & several others to see if there
> was any active work.  Nothing active that I know of.
>
> Anyways, I placed the sources under CVS and have been rewriting, fixing,
> adding to, and organizing the sources.  Once I figure out how
> to allow CVS server read-only access I'll announce that availibility
> to this list.
>
> I welcome any help & comments.
>         R.K.

Thanks for your work and the work of others on modules 3.0.2.  It is quite a useful package that has not received the credit it deserves.

I have also been successful in compiling the RKO modules version on Solaris 2.7, HP-UX 10.20 and SunOS 4.1.4.  The use of the configure utility make this so much easier than past versions of modules.

I do have some comments and suggestions:

   * The man page on modulefiles has at least two references to .modulesrc in the section on Locating Modulefiles.  The reference should be .modulerc (i.e. - drop the 's').  This had me running around in circles until I checked the source code.
   * The Locating Modulefiles section could use some rewrite to clarify the english.
   * The Locating Modulefiles section states that every directory is searched to find modulefiles and can have an arbitrary number of sub-directories.  This works as described.  However, the 'module list' and 'module avail' commands do not support reporting any more than the last two levels of this sub-directory structure.  As such, these two commands are broken.




     For many of you, two levels may be adequate, but our shop has been using three levels of modulefile directory structure for the past seven (7) years.   Modules 2.2beta handles this correctly.  We arrange this as the Package level, Release level, and local Revision level.  So for a package like Netscape, we have release 4.7, revision 'a' - module load netscape/4.7/a.  Any subsequent local changes setup environment to the initial release would be handled smoothly with a new module file
     revision 'b' - module load netscape/4.7/b.  Since a .version  file can be used to control the default at the release and revision levels, users can be isolated from changes to the default version (4.5, 4.6, 4.7...) and any local revisions (a,b,c...) when they simply 'module load netscape'.  Migration to new releases and levels is handled smoothy.  If trouble develops, this can be backed out smoothy too.

     So the bottom line here is that the modules 'list' and 'avail' need to be fixed to work with whatever number of sub-directories or levels exist to be in line with how the other module commands work.

   * The 'module -l list' command headings for 'Versions' is  incorrect in my opinion.  This is not really a column for the version, but the 'default' and other 'module-version' or 'module-alias' symbols defined in the modulefiles.  The source code (ModuleCmd_Avail.c in the print_aligned_files function) references this data as 'symbols'.  So 'Versions' should be changed to something more appropriate like 'Symbols'.
   * When the 'module list' and 'module avail' commands are fixed as recommended above, they must handle listing the 'default' flag or symbol appropriately at each level of module sub-directory structure.
   * The 'module-version' modulefile statement left me confused for some time with the words 'This command should be placed in one of the modulecmd rc files in order to provide shorthand invocations of frequently used module file names'.  I thought this would allow me to specify some 'alias_name' for a module file so that I could 'module load alias_name'.  Apparently, not so; these names only seem to apply within the context for the modulefiles.  So, aside from the special 'default'
     version-name, I am somewhat puzzled as to how to best take advantage of this modulefile statement.  I think some additional discussion and examples should be supplied in the man pages to further clarify the (intended) use of the module-version statement.
   * The 'module-alias' statement, as well, needs an expanded clarification of function, some discussion and examples of use.

That's enough for now.

Enjoy,
Dave