RE: [Modules] module update cause ModuleCmd_Use.c(224):ERROR:64

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

Mark Lakata (la...@mi...) wrote:

> I've added a new command to the tcl version that purges all 
> modules. This is useful for reseting the environment, ie.
> 
> .login:
> 
>  module purge
>  module load myproject/all
> 
> btw, has anyone else looked at the pure TCL version yet? 
> Unless you need deep modulefile trees (more than
> $tool/$version), there is no reason not to use the TCL
> version instead.  Installation on any machine (including
> cygwin) is as easy as
> 
> 1. first make sure tclsh in /usr/bin/ or /usr/local/bin 
>    or on the default system path
> 
> 2. 
>   mv modulecmd.tcl init /the/module/dir
>   cd /the/module/dir/init; make

Hi, Mark.

I'm not sure what you mean by those instructions above.  I
put modulecmd.tcl in a random place and set a new alias to
it:

% alias module '`eval /home/lbutler/bin/modulecmd.tcl tcsh \!*`'

Any reason that wouldn't work?  I don't see that it uses any
of the old init files from the C version.

Today, the Tcl version doesn't have all of the functionality
we use here in the C version.  I think we traded some emails
on this awhile back.  I have not tackled making all of the
updates necessary to get the features in there.  The ones I
recall are:

1. $env hash gets updated immediately during module unload,
   (when a setenv is undone) so any lines that use the value
   of the env var will cause an error.  I was able to fix
   this by just removing the "unset env($var)" in the setenv
   proc; no side-effects that I know of thus far.  Would
   there be any as far as you know?

2. During a module switch, the position of env vars is not
   the same as it was before (desirable in PATH).  The Tcl
   just does an unload then a load for the switch command.

3. Some modules just don't load although the command returns
   with no errors reported.  I'll need more time to dig into
   this one.

There may be more, but that was enough to prevent me from
switching without fixing these and doing more testing.
The first one is probably easy enough to fix, but the other
ones I'm not sure.  My Tcl coding skills are clearly not as
good as yours.

Note that my interest is indeed piqued about the Tcl version;
it holds the promise of being more portable and easier to
implement than the C version.  I'll make an effort to spend
some time on this in the next few weeks and get back to you.

Thanks,

- Leo