I have one called ssetup which I wrote. Originally, it was 'setup' (idea
stolen from VMS) but Redhat commandeered the name. My packages are stored,
one per directory, on a "packages" server which is NFS mounted on clients.
All the command does is run a .setup file in the appropriate directory which
actually does the proper environment setup.
Graham Allan wrote:
We have been using UPS/UPD from fnal for this (mainly for root and
packages like that):
http://www.fnal.gov/docs/products/ups/
Being somewhat disconnected from fnal here, I am not really sure how
well supported ups/upd is these days, it is hard to get much information
on it. I'd be interested if anyone from fnal might comment.
I guess the most popular package to do this kind of thing is "modules",
http://modules.sourceforge.net/
Graham
On Wed, May 27, 2009 at 06:09:57PM -0700, Matt Harrington wrote:
This isn't specifically a Scientific Linux question, but I suspect
many of the list's readers are in the same boat as me. We have about
30 scientific packages, of which about 20 are command-line only and
about 10 are GUI applications. Rather than have massive, slow, and
unmaintainable .cshrc/.bashrc files, people use an application called
"prepare" to set up each app as necessary. "prepare" originally came
from Johan Postma at EMBL Heidelberg and unfortunately its website
seems to have disappeared. It's a clever csh script which detects the
architecture in use and then sources an appropriate csh file to set up
environment variables and aliases. Originally it worked with IRIX and
OSF/1, and when Linux came on the scene I made the necessary
modifications. The idea is that "prepare ccp4" will set up the CCP4
package for whatever type of computer a user is currently using: SGI,
Tru64 Alpha, Linux Alpha, Linux x86, or Linux AMD64. Simply typing
"prepare" gives a list of applications currently configured for the
computer in use.
This has worked well, but I haven't revisited this issue in 15 years
and am wondering how the rest of the scientific world solves this
problem. All comments welcomed.
Matt
UCSF