modules-interest

Useful Features?

[Ian F. <fl...@cs...>]

Hi folks,

I'm new to the Modules system.  Until recently, I've been using a
similar system developed at Washington University in St. Louis called,
for lack of a better name, "the package system".  The main concept is
the same, both systems allow the user to modify their environment in
place.  There are some differences in the details and features that
I'd like to get other people's oppinions on.

For one, the package system uses a special startup file (.pkgrc) to
keep track of a user's default packages/modules.  The .pkgrc file is
merely a list of packages/modules that should be loaded into every
shell.  This is convenient since it's easy for a user to edit, it's
easy to programatically add and delete modules, and it doesn't involve
the shell's rc files at all.  This is good because it allows us to
give all users standard shell rc files *that they can't change*.
(We add a callout to a user startup file so that people can customize
their environment *after* all the global stuff is set up.)

Another difference is that the package system allows a user to force a
package/module to add things at the front or at the end of all the
paths.  This way users have more control over where things appear in
their paths.

The package system also has short descriptions in its listing of
available packages.  For example, it might look like:

    ars            Remedey Action Request System
    cwd            current working directory
    dxlib          direct X libraries (use with caution)
    gnu            almost all GNU utilities, including GCC, except Perl
    local          miscellaneous useful utilities
    netscape       Netscape's Navigator (3.0 Release)
    openwin        OpenWindows
    perl           Perl v5.003
    spro           SUNPro C & C++ compilers
    tcl            TCL -- Tool Command Language
    user           User's ~/bin and ~/man directories
    usr            standard bin and man directories (/bin, /usr/bin, etc.)
    usr-bsd        standard bin and man directories with BSD first
    usr-local      stuff in /usr/local/bin (Note: THIS WILL GO AWAY)
    usr-sysv       standard bin and man directories with SysV first
    xemacs         X-enhanced version of Emacs (better than GNU Emacs)

This gives users a good idea of what each package/module is without
having to ask explicitly.  If the user wants to find out what versions
are available, they do something like:

    flan@famine /home/flan> pkgversion netscape
    netscape_3.0
    netscape_3.0b7

I think it would be nice to have some sort of short listing like the
above in the Modules system.

As far as the package/module definition files go, the package system
uses "locks" to deal with conflicts instead of package/module names.
This way a package/module doesn't need to know what resources other
packages/modules use, it just needs to declare that it wants to use
some resource.  For example, a user should not have the packages
"usr-bsd" and "usr-sysv" at the same time.  In the package system,
they both declare that they use the "usr" resource.  All of the
resources are then documented so that everything works and plays well
together.

I'd like to know if people would find these features useful.  Because
of our current situation, it's necessary to implement some of these
features before we migrate to the Module system anyway.

Thanks for your time,

Ian Flanigan

Re: Useful Features?

[Dave W. <dwi...@Ba...>]

Ian,

  Let me know if you get any helpful responses.

  With respect to features, I think it might be useful to be able to add
a tool setup to the middle of a path (ahead of current applications, but
behind normal environment bins).  The only way to do this now (in
Modules) is unload all applications, and reload them in the correct
order.  I've toyed with the idea of having multiple sub-paths that get
fused together when a tool/application is setup.  For example:

$ENVIRONMENT_PATH = /bin:/usr/ucb:/usr/bin/:.
$APPLICATION_PATH = /xyz/synopsys/3.4b:/xyz/cadence/3.0

$PATH = ${ENVIRONMENT_PATH}:${APPLICATION_PATH}

  A tool setup for an application would append or prepend to the
APPLICATION_PATH, but these bins could never (?) eclipse the
ENVIRONMENT_PATH bins.  This takes a little more work to setup and could
probably be implemented in Modules or "the package system".  What are
you thoughts on this?  An implementation for this might include another
env var to determine how the $PATH gets built.  For example:

$PATH_RECIPE = ENVIRONMENT_PATH:APPLICATION_PATH

  As a step towards an implementation of this, all modulefiles I have
created source a common Tcl file at the end of loading.  This is where I
planned to do PATH build if that ever proved useful.  Would something
like this add much to the whole system? for users? for applications
admins?  for Network Eng?  Is there a better way to accomplish the same
thing?

  If you want to stop by some time we could discuss this over air
hockey.

  One last thing, let me know if you end up modifying Modules to add a
runtime (append/prepend) switch and change the conflict mechanism to a
lock mechanism.  I think it might be useful to also add a generic
parameter passing mechanism so that other misc args could be passed to
modulefiles.  This might facilitate future extensions.  Thoughts?

Dave