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
>