
Message: 5 Date: Fri, 23 Dec 2016 14:04:39 +1100 From: Craig Sanders <cas@taz.net.au> To: Luv Main <luv-main@luv.asn.au> Subject: Re: luv-main Digest, Vol 64, Issue 15 Message-ID: <20161223030439.alqgnoiollf6vuos@taz.net.au> Content-Type: text/plain; charset=us-ascii
On Fri, Dec 23, 2016 at 01:06:47PM +1100, Andrew Mather wrote:
We use the "modules" environment (TACC's lmod implementation specifically) for this type of thing.
https://www.tacc.utexas.edu/research-development/tacc-projects/lmod
It allows multiple versions of packages to exist without library collisions and so on. Loading the appropriate modules allows the user to set up the execution environment and even swap between versions if necessary.
this looks interesting. i'll have to read more about it but at first sight it seems like a specific language and system for setting up the environment for a particular program/script.
one of the main reasons i prefer wrapper scripts (or symlinks) is that they don't rely on undocumented and unknown settings (PATH, LDPATH, etc) in some random individual's environment. scripts document those settings explicitly. symlinks just use the standard system environment.
this has the huge benefit of NOT relying on fallible human memory, resulting in reproducible, auditable, and easily debugged software usage. also avoids seemingly random breakage from changes to the environment - "why doesn't this work? it ran perfectly 3 weeks ago when i last ran it."
i'm kind of surprised that a language with the slogan "explicit is better than implicit" is one of the main perpetrators of the #!/usr/bin/env abomination.
As Rodney mentioned, modules, or some variation thereof is quite common in HPC environments. Module files are generally set up by the admins, so they don't require anything more from the user than including the appropriate loading statements in their scripts. It's not unlike a wrapper script really. Through some of the other commands available, it also allows for querying of what modules and versions are available and what particular packages actually do. Our users are slowly getting used to this and beginning to check before asking for packages to be installed. One other advantage is that if configured, modules allows for logging, which can help in software management. -- - https://picasaweb.google.com/107747436224613508618 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- "Voting is a lot like going to Bunnings really: You walk in confused, you stand in line, you have a sausage on the way out and at the end, you wind up with a bunch of useless tools" Joe Rios -

On Fri, Dec 23, 2016 at 02:44:28PM +1100, Andrew Mather wrote:
Module files are generally set up by the admins, so they don't require anything more from the user than including the appropriate loading statements in their scripts. It's not unlike a wrapper script really.
it sounds similar to (but quite a bit more advanced than) what i've done in the past with wrapper scripts and collections of environment setting files sourced (#included) as needed. craig -- craig sanders <cas@taz.net.au>
participants (2)
-
Andrew Mather
-
Craig Sanders