RE: Modules 3.1.3 and beyond?

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

> [snip]
>
> > The purpose of this latest version, was to fix all the known bugs
> [more snippage]
>
> Hello, Dr. Owen.
>
> First of all, it's great to hear from you -- it's been awhile and
> the modules-interest list has been kinda quiet.  Thanks for the
> big update; I'll build and begin testing today.
>
> I posted a bug in the Sourceforge problem report area last week;
> do those postings generate an email to you and/or Robert Minsk?
> I thought to send a message to the list, but I thought it would
> be redundant.
>
 ...
>
> Best regards,
>
> - Leo Butler
>
>

Hello Leo, I've included the text from the bug report, so others
can appreciate the problem, and I answer below.

> 
> When a modulefile itself loads a modulefile, the 
> second-level modulefile doesn't have its .version file 
> loaded during a switch command. Seems to work correctly 
> during module load and module unload commands. 
> 
> With attached test files, do the following: 
> 
> % module load Proj/A 
> % module switch Proj Proj/B 
> 
> Note the following messages: 
> 
> opus:modulefiles> module switch Proj Proj/B 
> Proj/A: mode is switch1 
> Proj/A: Info exists TEST_VER == 1 
> .version: setting TEST_VER to 1 
> Test/1: mode is switch1 
> Proj/B: mode is switch2 
> Proj/B: Info exists TEST_VER == 1 
> Test/1: mode is switch2 
> Proj/A: mode is switch3 
> Proj/A: Info exists TEST_VER == 1 
> Test/1: mode is switch3 
> 
> There are two problems in the above debug messages: 
> 
> 1. There should be a ".version: setting TEST_VER to 2" 
> below "ProjB: Info exists TEST_VER == 1" indicating 
> that the "module load Test" command in the B modulefile 
> loaded the .version file, but there is none so the 
> wrong version was loaded. 
> 
> 2. The "ProjB: Info exists TEST_VER == 1" line should 
> indicate that TEST_VER == 2, but it incorrectly shows 
> 1. If a "module load Proj/B" is done, you will see that 
> the "setenv TEST_VER 2" results in $env(TEST_VER) being 
> set properly, but it isn't during a switch as shown 
> above. 
> 
> Thanks, 
> 
> - Leo Butler 
> mailto:lb...@br... 

I've looked at this behavior, and what is happening is that modules
caches any `default' modules.  I.e. Test -> Test/1 when it first locates
and reads Proj/A.  So late when it needs to resolve Test ... it sees
that it had already resolved it via the .version/.modulerc/or position
in the directory and re-uses it.  This is probably considered `good'
behavior and also would require extensive changes to change this.

I notice that your modulefiles are wonderfully complicated testing
the limits of modules.
Generally .version files are simply to do a "set Module-version".  However, by
rewriting your modulefiles a bit, I think you can get the desired behavior.

First, a "setenv" in a modulefile does not change the env.var. for
the modulecmd process as it is running.  ... It only outputs the
necessary commands to be evaluated by the shell.  To set the
process environment you must do it the Tcl way. e.g.
	set env(TEST_VER) 2
Therefore, notice where I put these in.

Once I change the modulefiles I get output like this:

$ modulecmd csh swap Proj Proj/B

Proj/A: mode is switch1
Proj/A: Info exists TEST_VER == 1
Test/.version: mode is load
.version: setting TEST_VER to 1
Test/1: mode is switch1
Proj/B: mode is switch2
Proj/B: setting TEST_VER to 2
Proj/B: Info exists TEST_VER == 2
Test/2: mode is switch2
Proj/A: mode is switch3
Proj/A: Info exists TEST_VER == 2
Test/2: mode is switch3

setenv TEST_PATH '/u/owen/rk/test2';setenv TEST_VER '2';setenv _LMFILES_ '/usr/local/Modules/3.1.3/modulefiles/modules:/usr/local/Modules/3.1.3/modulefiles/use.own:/u/owen/rk/privatemodules/Test/2:/u/owen/rk/privatemodules/Proj/B';setenv LOADEDMODULES 'modules:use.own:Test/2:Proj/B';setenv PROJECT 'B';

Where the modulefiles are:
Proj A (B is similar to this):

#%Module######################################################################
##
##	ProjA Module
##
proc ModulesHelp { } {
    puts stderr "\tProjA\n"
    puts stderr "\tSets up thie "A" project.\n"
}

# Prequisites and conflicts

conflict Proj

setenv PROJECT          A

puts stderr "Proj/A: mode is [module-info mode]\n";

if {[module-info mode load] || [module-info mode switch2]} {
  puts stderr "Proj/A: setting TEST_VER to 1\n";
  setenv TEST_VER 1;
  set env(TEST_VER) 1
}

if [info exists env(TEST_VER)] {
  puts stderr "Proj/A: Info exists TEST_VER == $env(TEST_VER)\n";
  module load Test/$env(TEST_VER);
}

## End of module

Test/1 (2 is similar to this):
#%Module######################################################################
##
##	Test Module
##
proc ModulesHelp { } {
    puts stderr "\tTest\n"
    puts stderr "\tAllows testing"
}

puts stderr "Test/1: mode is [module-info mode]\n";

setenv TEST_VER 1
append-path  TEST_PATH  $env(HOME)/test1

Test/.version:
#%Module1.0
##
##  The desired version of Test
##
set ModulesVersion "1"
puts stderr "Test/.version: mode is [module-info mode]\n";
if { [info exists env(TEST_VER)] } {
    puts stderr ".version: setting TEST_VER to $env(TEST_VER)\n"
    set ModulesVersion $env(TEST_VER)
}


------------------------------------------------------------------------
Therefore, it looks like this is a `feature' and not a bug.

Hope this is helpful to you.
	R.K.

+-----------------------+----------------------------------+
| R.K.Owen,PhD          | rk...@ow...   (408)377-5373 |
| KooZ Software         |                                  |
| NERSC/LBNL            | rk...@ne...   (510)486-7556 |
+-----------------------+----------------------------------+