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. craig -- craig sanders <c...@taz.net.au> _______________________________________________ luv-main mailing list luv-main@luv.asn.au https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
