>From a command-line standpoint, things work out very well in
the current implementation since your last example does
indeed work. So modules is already plenty smart enough to
know which modulefile versions are already loaded, and so it
can swap out a current version no problem. It might be a
nice syntax extension, but I feel there're bigger fish to fry.
(What? Who brought up fish? :-)
What I *think* is happening in my example is that modules
doesn't know to do anything except unload proj1 (and by
extension, only the specific modulefile versions that were
"load"ed in that file). My (possibly wrong-headed) version
of what I think modules should do in this case is kinda like
module switch Project Project/proj2
(okay, Project/proj1 is the currently loaded Project
modulefile. I'll open it to see what I have to unload.)
(ah-hah! I see a "module load Synopsys/1999.05" command
in the current version of Project <proj1>. I'll try to
(uh-oh, Synopsys/1999.05 isn't loaded any longer, so
either Synopsys was unloaded or another version was
switched after modulefile "proj1" was loaded. I'll
either unload the current version, or if indeed no
version of Synopsys is loaded, I'll just do nothing
for this item and move on.)
What it does today in the third step is instead to bomb out
with an error since some of the "setenv" statements don't
match the current environment, so it can't find them to
So I think modules ought to do something similar to what you
wanted to see, which is an inferred alternate modulefile
to unload. But it needs to happen on the "module load"
statement inside another modulefile when modules is undoing
the load (which in this case would just be an unload).
I think if I didn't use specific versions of modulefiles in
proj1 and proj2 that modules would then know to go unload
the currently loaded version, but being forced to load the
default versions totally defeats the purpose of separate
project files where the two projects need to use different
versions of applications. Alas...
Mark Lakata wrote:
> I have exactly the same problem. One wish-list item I would like, which
> might solve this problem, is that the 'switch' command can take only one
> argument (the new module) and determine the old module from what is
> currently loaded. i.e.
> module load Synopsys/1999.10
> module switch Synopsys/1999.05
> This makes the assumption that the module in question has the naming
> convention "tool/version", which I think is common practice for vendor
> tools. The switch command will do a pattern match in the 'module list'
> for Synopsys/*, unload that and then load the requested module. In fact,
> this already happens to some extent, since you can do
> module switch Synopsys Synopsys/1999.05
> Mark Lakata
> MIPS Technologies
> 1225 Charleston Road
> Mountain View, CA 94043
> phone 650-567-5170
> fax 650-567-5002
> email lakata@...
> On Wed, 15 Mar 2000, Leo Butler wrote:
> > G'day, all.
> > I've set up modulefiles for all of the CAD applications in
> > use at my company, and I've set up a couple of modulefiles
> > for two separate projects that load the correct versions of
> > applications for that project. I want users to be able to
> > switch between two (or any number of) projects and have any
> > interactive changes they may have made to approved versions
> > not mess up the module unload (or switch).
> > For instance, say I do a
> > % module load Projects/proj1
> > which in turn loads up modules for Synopsys/1999.05, VCS/5.0
> > and Apollo/3.3.0.EA9. But I'm evaluating Synopsys/1999.10 on
> > this project, so I
> > % module switch Synopsys/1999.05 Synopsys/1999.10
> > Okay, so far so good. But now I want to load up another
> > project, so I do a
> > % module switch Projects/proj1 Projects/proj2
> > and I get an error because proj1 wants to unload Synopsys/1999.05
> > but I've secretly replaced this version since proj1 was loaded.
> > What's the correct way to manage this sort of situation? It
> > is very real-world but I may be approaching it incorrectly.
> > I do know that I want the user to not worry about what they
> > may have done interactively and I don't want them to have to
> > effectively do a
> > % module purge (or clear)
> > % module load dot GNU system admin user local
> > % module load X11 CDE
> > % module load Projects/proj2
> > even by hiding this away in another modulefile.
> > I then looked for a mechanism to figure out if a particular
> > module was loaded from inside a modulefile so I could do a
> > "if (exists any_version_of_Synopsys) then module unload Synopsys"
> > but none of the commands seem to support this.
> > Thanks in advance for any assistance on this!
> > Regards,
> > - Leo
> > ----------------------------------------------------------------------
> > Leo Butler Senior Engineer
> > Brocade Communications Phone: (408) 487-8096
> > 1901 Guadalupe Parkway Fax: (408) 487-8090
> > San Jose, CA 95131 mailto:lbutler@...
Leo Butler Senior Engineer
Brocade Communications Phone: (408) 487-8096
1901 Guadalupe Parkway Fax: (408) 487-8090
San Jose, CA 95131 mailto:lbutler@...