modules-interest — Discussion forum for modules usage.

problems with null module in 3.1.5

[<gi...@ki...>]

Hi,

module load null produces

null(18):ERROR:102: Tcl command execution failed: 3.1.5

what does that mean?

Thanks in advance,

Gintas

ibiblio action notice from the `keeper' program

[Linux K. <ke...@me...>]

At about 2001-08-21 13:15:47 UCT, `keeper' moved the following files from
Incoming to utils/shell (things you need for doing serious shell programming):

modules-3.1.4-3.1.5.diff.bz2 provides for the dynamic modification of a user's environment via modulefiles.
modules-3.1.4-3.1.5.diff.gz provides for the dynamic modification of a user's environment via module files
modules-3.1.5.tar.bz2    provides for the dynamic modification of a user's environment via module files
modules-3.1.5.tar.gz     provides for the dynamic modification of a user's environment via module files
modules.lsm              

Thank you for your contribution of time, effort, and creativity.

This message was a form letter generated by keeper 1.54, but replying to
it will reach the human who told keeper what to do.  You got this note
because you're listed as a maintainer or author in the archive part involved.
If your package was actually uploaded by someone else, and you know who that
person is, please try to get that person to list him or herself in the LSM.  
--
			Serena Fenton (ibiblio co-maintainer)
			fe...@ib...

Re: Exit from Module load without actually loading

[Lloyd C. C. <lc...@po...>]

Once upon a time (like on Aug 10, 2001), Scott Gaskins wrote:
> But what I want is some more elegant and meaningful message like:
>   # module load apps/verilint
>   Note: The module 'apps/verilint' is not available for Linux.
> 
> So currently I have hacked up lots of 'dummy' modules that match most of
> the modules in our AIX modulefiles directory but really are symbolic links
> back to a single module file called 'notavail'.  In the second example
> above, I use a symlink from modulefiles/apps/verilint ->

What I have been doing is to use a single modulefile directory shared
among all the platforms that we support.  The modules have specific
instructions based on the OS detected.  These are selected via a
switch statement such as the following:

#--------------------------------------------------------------------------
set os [join [list [uname sysname] [uname release]]]
switch -glob $os {
   "SunOS 5.*" {
      # SunOS 5.x specific stuff
   }
   "SunOS 4.*" {
      # SunOS 4.x specific stuff
   }
   "HP-UX B.10*" -
   "Linux*" -
   "AIX*"   -
   "HP-UX*" {
      append-path PATH $env(EXAMPLE)/bin
      append-path LM_LICENSE_FILE 1700@lic-serv

      # Common stuff
      common_proc
   }
}

Exit from Module load without actually loading

[Scott G. <sga...@us...>]

I am trying to put together a module facility for Linux that will be
somewhat backward compatible with our existing module facility (running on
AIX).
Along these lines, I want to allow users to load modules for their
individual projects, where each project module file will do lots of
individual other module loads.  Unfortunately, I do not have all of the
same tools available for Linux that we have on AIX, so there are lots of
modules in these project modulefiles that I cannot support for Linux.

Currently, if the module in a project's modulefile is not found on my Linux
modulefile directory, I get an ugly error message like:
  # module load some_aix_tool
  ModuleCmd_Load.c(199):ERROR:105: Unable to locate a modulefile for
'some_aix_tool'

But what I want is some more elegant and meaningful message like:
  # module load apps/verilint
  Note: The module 'apps/verilint' is not available for Linux.

So currently I have hacked up lots of 'dummy' modules that match most of
the modules in our AIX modulefiles directory but really are symbolic links
back to a single module file called 'notavail'.  In the second example
above, I use a symlink from modulefiles/apps/verilint ->
modulefiles/notavail.  I looked through the module source code and found
out that if, at the end of the 'notavail' module, I pass back a return code
of '11' (or any other number that doesn't happen to match 'TCL_OK' or
'TCL_ERROR'), then I can get the module file to display the warning note
and not actually add itself to the list of loaded modules.

I am posting this here for two reasons:
1) Is there a more elegant way to handle this -- ie. can I define a default
module that is executed (without being loaded) whenever a 'module load'
command doesn't find it's target?
2) Is there any reason that it may be unsafe to pass return values back
from modulefiles like I am currently doing?

Here is my 'notavail' module:
#%Module1.0#####################################################################
##
## notavail modulefile
##

proc ModulesHelp { } {
        global version

        puts stderr "\tThis module does absolutely nothing."
        puts stderr "\tIt's meant simply as notice to the user"
     puts stderr "\tthat the [module-info name] module"
        puts stderr "\tis not available at this time."
        puts stderr "\n\tVersion $version\n"
}

module-whatis  "Notifies user that module is not available."

# for Tcl script use only
set     version      "3.1.3"
set curMod [module-info name]

if { [ module-info mode load ] } {
    puts stderr "Note: The module '$curMod' is not available for [uname
sysname]."
}

#Return code 11 == do not add this module to the loaded modules list
return 11


Thank you,
-------------------------------------------
W. Scott Gaskins
T/L 441-9863
(919) 543-9863
sga...@us...
IBM Bldg062/C215
P.O. Box 12195 - YM6A/062
3039 Cornwallis Rd
RTP, NC 27709

(PS.. If this mail is poorly formated, blame Lotus Notes' stupid insistance
that everything going out to the internet be word-wrapped at 80
characters!!)

Delete hash table on failed module command

[Eric S. <bar...@kn...>]

All,

I am using modules 3.1.4.  I have a module file, standard, that has
several module load commands in it.  If some of the modules which are
loaded by the 'standard' module are not present, the modulecmd program
will sometimes delete the setenvHashTable after the module load
command fails.  This appears to happen only when the version of the
module file being loaded is _NOT_ specified.  The result of this is
that not all the environment changes make it into the calling
environment.  In fact only those which happened after the last
Tcl_DeleteHashTable() call.

I know I could fix this by supplying the rest of the module files (and
I will eventually), but it seems to me that the hash table should
never be deleted on a failed module load command.

I would be glad to supply more information on this issue.

Thanks.

Eric

ibiblio action notice from the `keeper' program

[Linux K. <ke...@me...>]

At about 2001-08-07 14:40:26 UCT, `keeper' moved the following files from
Incoming to kernel (kernel sources and patches):

modules-3.1.3-3.1.4.diff.bz2 module utils for kernels 2.0.0 and later
modules-3.1.3-3.1.4.diff.gz module utils for kernels 2.0.0 and later
modules-3.1.4.tar.bz2    module utils for kernels 2.0.0 and later
modules-3.1.4.tar.gz     module utils for kernels 2.0.0 and later
modules.lsm              

Thank you for your contribution of time, effort, and creativity.

This message was a form letter generated by keeper 1.54, but replying to
it will reach the human who told keeper what to do.  You got this note
because you're listed as a maintainer or author in the archive part involved.
If your package was actually uploaded by someone else, and you know who that
person is, please try to get that person to list him or herself in the LSM.  
--
			Serena Fenton (ibiblio co-maintainer)
			fe...@ib...

Modules 3.1.4

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

Hello all:
I've released Modules 3.1.4 which addresses the following changes:

Modules 3.1.4
Fri Aug  3 12:45:55 PDT 2001		R.K. Owen (rk...@ow...)
* Some preliminary steps to a rpm file.
* Added bz2 files to distribution mix.
* Fixed "module swap" to put the substituted module in the
  same path location as the old.  Also added a number of tests
  for this feature.
  (Bug was pointed out by Leo Butler <lb...@br...>)
* Added tests for the "is-loaded" modulefile command introduced
  back in 3.0.8-rko.
* Fixed up some documents.

You can go to http://modules.sourceforge.net/ for the ftp links (thanks
to Leo Butler for maintaining the web page).

I'm also working on creating a RedHat 7.1 RPM file that will
install the modules environment, etc..

We also need someone who is a master at configuration/autoconf files to
clean up and modernize the distribution one and to fix some nits (like
a recent one posted here - not using ``-ltcl8'' instead of ``-ltcl'').

As always comments & suggestions  are welcomed (but not as much
as code patches ;^)
	R.K.

+------------------+---------------------+
| R.K.Owen,PhD     | rk...@ow...    |
| KooZ Software    | Environment Modules |
| NERSC/LBNL       | rk...@ne...    |
+------------------+---------------------+

Re: Archives?

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

>
> I'm having some difficulty with modules v3.1.3 on Linux, but I'd like
> to search the archives before bothering anyone with my question.  Are
> archives available for this list?  If so, where?
>
> Thanks.
>
> Eric
>
The archive can be found at
http://www.eng.auburn.edu/users/cross/www/pub/mail-lists/modules-interest/index.html

I think Leo Butler will get a link to it from modules.sourceforge.net
in the near future.
	R.K.

+------------------+---------------------+
| R.K.Owen,PhD     | rk...@ow...    |
| KooZ Software    | Environment Modules |
| NERSC/LBNL       | rk...@ne...    |
+------------------+---------------------+

Archives?

[Eric S. <bar...@kn...>]

I'm having some difficulty with modules v3.1.3 on Linux, but I'd like
to search the archives before bothering anyone with my question.  Are
archives available for this list?  If so, where?

Thanks.

Eric

RE: linker problems [was Now I know why its free]

[Chris R. <Chr...@ca...>]

The tcl library can either be a .a extension or a .so extension

Tell the Configure script to use libtcl8.x.so as the tcl library.



/* ---
     Christopher M. Rumpf
     Calix
     --- */

-----Original Message-----
From: Ric Rocheleau [mailto:Ric...@ca...]
Sent: Wednesday, July 18, 2001 1:45 PM
To: 'ed...@ul...'; Ric Rocheleau
Cc: 'Harlan Stenn'; mod...@En...
Subject: RE: linker problems [was Now I know why its free]




Hmm - something must be amiss with my tcl build as that 
was what I expected, but no libtcl.a or libtcl8.3.a exists


r

-----Original Message-----
From: Edward Arthur [mailto:ed...@ul...]
Sent: Wednesday, July 18, 2001 4:38 PM
To: Ric Rocheleau
Cc: 'Harlan Stenn'; mod...@En...
Subject: Re: linker problems [was Now I know why its free]


It definitely wants your tcl library.

% ls -l /usr/local/lib | grep tcl
-rw-r--r--   1 root     other     931436 Oct  4  2000 libtcl.a
-r-xr-xr-x   1 root     other    3511708 Oct  5  2000 libtcl8.0.a
-r-xr-xr-x   1 root     other     931436 Oct 13  2000 libtcl8.3.a
-r-xr-xr-x   1 root     other     688484 Sep  8  2000 libtcl8.3.so
-rw-r--r--   1 root     other       1888 Oct 13  2000 libtclstub8.3.a
drwxr-xr-x   8 root     other       8192 Oct 13  2000 tcl8.3
-rw-r--r--   1 root     other       6726 Oct 13  2000 tclConfig.sh

In our case libtcl.a is the same thing as libtcl8.3.a (based on the size).

/Ed

Ric Rocheleau wrote:
> 
>         Thought that too.  Didnt help.  Thanks I'll poke around some more
> 
>         r
> 
> -----Original Message-----
> From: Harlan Stenn [mailto:Har...@pf...]
> Sent: Wednesday, July 18, 2001 4:16 PM
> To: Ric Rocheleau
> Cc: mod...@En...; Har...@pf...
> Subject: Re: Now I know why its free
> 
> It wants the tcl library, but later versions of tcl install as libtcl8*.*
> instead of libtcl.* .
> 
> Make a "suitable" link...
> 
> H

RE: linker problems [was Now I know why its free]

[Ric R. <Ric...@ca...>]

Hmm - something must be amiss with my tcl build as that 
was what I expected, but no libtcl.a or libtcl8.3.a exists


r

-----Original Message-----
From: Edward Arthur [mailto:ed...@ul...]
Sent: Wednesday, July 18, 2001 4:38 PM
To: Ric Rocheleau
Cc: 'Harlan Stenn'; mod...@En...
Subject: Re: linker problems [was Now I know why its free]


It definitely wants your tcl library.

% ls -l /usr/local/lib | grep tcl
-rw-r--r--   1 root     other     931436 Oct  4  2000 libtcl.a
-r-xr-xr-x   1 root     other    3511708 Oct  5  2000 libtcl8.0.a
-r-xr-xr-x   1 root     other     931436 Oct 13  2000 libtcl8.3.a
-r-xr-xr-x   1 root     other     688484 Sep  8  2000 libtcl8.3.so
-rw-r--r--   1 root     other       1888 Oct 13  2000 libtclstub8.3.a
drwxr-xr-x   8 root     other       8192 Oct 13  2000 tcl8.3
-rw-r--r--   1 root     other       6726 Oct 13  2000 tclConfig.sh

In our case libtcl.a is the same thing as libtcl8.3.a (based on the size).

/Ed

Ric Rocheleau wrote:
> 
>         Thought that too.  Didnt help.  Thanks I'll poke around some more
> 
>         r
> 
> -----Original Message-----
> From: Harlan Stenn [mailto:Har...@pf...]
> Sent: Wednesday, July 18, 2001 4:16 PM
> To: Ric Rocheleau
> Cc: mod...@En...; Har...@pf...
> Subject: Re: Now I know why its free
> 
> It wants the tcl library, but later versions of tcl install as libtcl8*.*
> instead of libtcl.* .
> 
> Make a "suitable" link...
> 
> H

Re: linker problems [was Now I know why its free]

[Edward A. <ed...@ul...>]

It definitely wants your tcl library.

% ls -l /usr/local/lib | grep tcl
-rw-r--r--   1 root     other     931436 Oct  4  2000 libtcl.a
-r-xr-xr-x   1 root     other    3511708 Oct  5  2000 libtcl8.0.a
-r-xr-xr-x   1 root     other     931436 Oct 13  2000 libtcl8.3.a
-r-xr-xr-x   1 root     other     688484 Sep  8  2000 libtcl8.3.so
-rw-r--r--   1 root     other       1888 Oct 13  2000 libtclstub8.3.a
drwxr-xr-x   8 root     other       8192 Oct 13  2000 tcl8.3
-rw-r--r--   1 root     other       6726 Oct 13  2000 tclConfig.sh

In our case libtcl.a is the same thing as libtcl8.3.a (based on the size).

/Ed

Ric Rocheleau wrote:
> 
>         Thought that too.  Didnt help.  Thanks I'll poke around some more
> 
>         r
> 
> -----Original Message-----
> From: Harlan Stenn [mailto:Har...@pf...]
> Sent: Wednesday, July 18, 2001 4:16 PM
> To: Ric Rocheleau
> Cc: mod...@En...; Har...@pf...
> Subject: Re: Now I know why its free
> 
> It wants the tcl library, but later versions of tcl install as libtcl8*.*
> instead of libtcl.* .
> 
> Make a "suitable" link...
> 
> H

RE: Now I know why its free

[Ric R. <Ric...@ca...>]

	Thought that too.  Didnt help.  Thanks I'll poke around some more

	r

-----Original Message-----
From: Harlan Stenn [mailto:Har...@pf...]
Sent: Wednesday, July 18, 2001 4:16 PM
To: Ric Rocheleau
Cc: mod...@En...; Har...@pf...
Subject: Re: Now I know why its free 


It wants the tcl library, but later versions of tcl install as libtcl8*.*
instead of libtcl.* .

Make a "suitable" link...

H

Re: Now I know why its free

[Harlan S. <Har...@pf...>]

It wants the tcl library, but later versions of tcl install as libtcl8*.*
instead of libtcl.* .

Make a "suitable" link...

H

Now I know why its free

[Ric R. <Ric...@ca...>]

	Anyone know what this tool is looking for?

	gcc -o modulecmd -L/usr/local/pkg/tcltk/8.3.3/lib   -L/usr/X11/lib
-R/usr/X11/lib -R/usr/X11/lib:/usr/local/pkg/tcltk/8.3.3/lib -g
ModuleCmd_Avail.o ModuleCmd_Clear.o ModuleCmd_Display.o ModuleCmd_Help.o
ModuleCmd_Init.o ModuleCmd_List.o ModuleCmd_Load.o ModuleCmd_Purge.o
ModuleCmd_Switch.o ModuleCmd_Update.o ModuleCmd_Use.o ModuleCmd_Whatis.o
cmdAlias.o cmdConflict.o cmdIsLoaded.o cmdInfo.o cmdMisc.o cmdModule.o
cmdPath.o cmdSetenv.o cmdUname.o cmdXResource.o cmdUlvl.o cmdLog.o
cmdTrace.o cmdVersion.o cmdVerbose.o cmdWhatis.o init.o locate_module.o
utility.o main.o error.o getopt.o version.o -ltcl -lXmu -lXt -lX11  -ldl -lm
-lnsl -lsocket 
ld: fatal: library -ltcl: not found
ld: fatal: File processing errors. No output written to modulecmd
collect2: ld returned 1 exit status
make: *** [modulecmd] Error 1



 <<Ric Rocheleau.vcf>> 

Re: Modules 3.1.3 and beyond?

[David C. M. <dav...@ba...>]

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

>
> I like to group my modules into categories. For example,
> browsers/netscape/4.61, browsers/netscape/6.0, browsers/opera/4.0, etc.
> and what happens is that the .version files don't get read. Say
> browsers/netscape/.version points to 4.61 which is totally ignored and
> netscape/6.0 will be loaded if doing "module load browsers/netscape"
>

Glad to see that you are back working on modules again.  We are a shop that
uses "deep modulefile directories", and I will be very interested when you
solved the deep .version files problem you have described above.  It is the
show stopper that is preventing our move to modules 3.x.

>From a historical perspective modules 2.x supports deep modulefile
directories.  An unfortunate side effect of the subsequent development
efforts for new modules functionality apparently broke that feature.

Even if  may folks do not use or appreciate the value of deep modulefile directories,
modules operation should be consistent throughout - e.g. if 'module avail/load/unload'
supports deep modulefile directories, then all aspects of that support (i.e.
.version files) should follow.  I would have thought that if these routines had been
coded in a recursive style, then the operation of .version files would have
never come up as an issue in the deeper directories.  However, that is water
over the dam.....


Dave

Can someone translate

[Ric R. <Ric...@ca...>]

	Hi all

	Keep running into this symbol ref error during compile of
Modules-3.1.3
	 and my brain is melting 

	ld: fatal: Symbol referencing errors. No output written to modulecmd
	collect2: ld returned 1 exit status
	make: *** [modulecmd] Error 1


	Being that I am not a compiler guy - 

	Anyone care to translate this from the PROBLEMS file in
Modules-3.1.3 dist?

SOLARIS
-------

IF you really want a static binary, you will have to make sure to
link everything EXCEPT `-ldl' static. This you control with the
option -Bstatic and -Bdynamic. GCC doesn't support this, so you
must call the `ld' directly...

Also, if you have X11 support, and want a static binary in OW3.3,
you must add these libraries as well:

        -lsocket -lnsl -lw -lintl




 <<Ric Rocheleau.vcf>> 

MetaLab action notice from the `keeper' program

[Linux K. <ke...@me...>]

At about 2001-07-17 19:13:16 UCT, `keeper' moved the following files from
Incoming to utils/shell (things you need for doing serious shell programming):

modules-3.1.2-3.1.3.diff.gz provides for the dynamic modification of a user's environment via module files
modules-3.1.3.tar.gz     provides for the dynamic modification of a user's environment via module files
modules.lsm              

Thank you for your contribution of time, effort, and creativity.

This message was a form letter generated by keeper 1.54, but replying to
it will reach the human who told keeper what to do.  You got this note
because you're listed as a maintainer or author in the archive part involved.
If your package was actually uploaded by someone else, and you know who that
person is, please try to get that person to list him or herself in the LSM.  
--
			keeper (MetaLab co-maintainer)

Re: Modules on Solaris 8

[Mark L. <la...@mi...>]

You should be using a much newer version of tcl for modules-3.+... (I'm
not sure what is the best, but >= 8.0 for sure).  I've got some patches
for modules-2.2 if you want to use tcl8.1


Mark Lakata, Staff Engineer    1225 Charleston Road       voice 650-567-5170
MIPS Technologies              Mountain View CA 94043     fax   650-567-5002

On Tue, 17 Jul 2001, Ric Rocheleau wrote:

> 
> 
> 	Do Modules run on Solaris8?   I am not able to build tcl6.5 on
> Solaris8
> 	Several compile errors usng gcc.  Am I wasting my time?
> 
> 	regards
> 	Ric 
> 	Calix
> 
> 	
> 
> 
> 
> 
>  <<Ric Rocheleau.vcf>> 
> 

Modules on Solaris 8

[Ric R. <Ric...@ca...>]

	Do Modules run on Solaris8?   I am not able to build tcl6.5 on
Solaris8
	Several compile errors usng gcc.  Am I wasting my time?

	regards
	Ric 
	Calix

	




 <<Ric Rocheleau.vcf>> 

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 |
+-----------------------+----------------------------------+

RE: Modules 3.1.3 and beyond?

[Leo B. <lb...@br...>]

"R.K. Owen Ph.D." <rk...@ow...> wrote:

> > > The purpose of this latest version, was to fix all the known
> > > bugs
> > [more snippage]
> 
> At least known by me.  Sorry to say, I did not look at the
> SourceForge bug tracker items.  I'm just used to looking at bugs
> submitted to this list.  I'll have to figure out how to get
> SourceForge to email me when new bugs are submitted.

Hello, Dr. Owen.

No worries; it wasn't a deadly bug by any means, otherwise I
would have posted to the list as well.

> > 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.
> 
> I just noticed it now.  However, there were no .version files in the
> download tar ball.  If the problem persists, and it's not related
> to deep directories, then upload them again with the .version files.
> I'll try to fix it.

I've sent the file separately.

> > > 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..
> >
> > [snip]
> >
> > I wish I had something intelligent to offer on this, but it's
> > so unnecessary in our usage of modules that it's a don't-care
> > to me... I wonder if any of the requestors of the feature might
> > be able to expand on their usage model so this lost soul could
> > better understand the need for these changes?  I hate it when
> > my clue meter isn't registering...
> 
> I like to group my modules into categories. For example,
> browsers/netscape/4.61, browsers/netscape/6.0, browsers/opera/4.0, etc.
> and what happens is that the .version files don't get read. Say
> browsers/netscape/.version points to 4.61 which is totally ignored and
> netscape/6.0 will be loaded if doing "module load browsers/netscape"

Thank you for spelling it out for me.  It makes perfect sense.

> We really could use someone to put up web pages up on
> modules.sourceforge.net.  If I do it, then the pages will
> turn out rather bland.

I'd be happy to take a stab at it; I do some HTML both at home
and work so I'm at least above the clueless level there.  Okay,
a little better than that even.  Throw some requirements my way
(content, example of good sourceforge page to look at, etc.) and
I'll get started.

> Thanks for the input,

Likewise!

- Leo Butler

RE: Modules 3.1.3 and beyond?

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

>
> > The purpose of this latest version, was to fix all the known bugs
> [more snippage]

At least known by me.  Sorry to say, I did not look at the SourceForge
bug tracker items.  I'm just used to looking at bugs submitted to this list.
I'll have to figure out how to get SourceForge to email me when new bugs
are submitted.

I have noticed that I've left some documentation in a embarrassingly
turbulent state, which I will clean up, but the code itself should be
pretty good.

>
> 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.

I just noticed it now.  However, there were no .version files in the
download tar ball.  If the problem persists, and it's not related
to deep directories, then upload them again with the .version files.
I'll try to fix it.

>
> > 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..
>
> [snip]
>
> I wish I had something intelligent to offer on this, but it's
> so unnecessary in our usage of modules that it's a don't-care
> to me... I wonder if any of the requestors of the feature might
> be able to expand on their usage model so this lost soul could
> better understand the need for these changes?  I hate it when
> my clue meter isn't registering...

I like to group my modules into categories. For example,
browsers/netscape/4.61, browsers/netscape/6.0, browsers/opera/4.0, etc.
and what happens is that the .version files don't get read. Say
browsers/netscape/.version points to 4.61 which is totally ignored and
netscape/6.0 will be loaded if doing "module load browsers/netscape"

>
> [big snip]
>
> > 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).
>
> If it might make the code more approachable for a (newbie)
> programmer such as myself, I'd love to see it.  Of all the
> open source projects I've benefited from, modules is the one
> that I'd most like to contribute to.

We really could use someone to put up web pages up on
modules.sourceforge.net.  If I do it, then the pages will
turn out rather bland.

>
> Best regards,
>
> - Leo Butler
>
>
Thanks for the input,
	R.K.

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

RE: Modules 3.1.3 and beyond?

[Leo B. <le...@le...>]

R.K. Owen Ph.D. (rk...@ow...) wrote:

> 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.

[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.

> 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..

[snip]

I wish I had something intelligent to offer on this, but it's
so unnecessary in our usage of modules that it's a don't-care
to me... I wonder if any of the requestors of the feature might
be able to expand on their usage model so this lost soul could
better understand the need for these changes?  I hate it when
my clue meter isn't registering...

[big snip]

> 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).

If it might make the code more approachable for a (newbie)
programmer such as myself, I'd love to see it.  Of all the
open source projects I've benefited from, modules is the one
that I'd most like to contribute to.

Best regards,

- Leo Butler

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.)