SoftEnv vs Environment Modules.
pro and cons
both lack dev
modules allow for user extension


SoftEnv 101

 .profile source softenv.  .soft list all default pkg that should be loaded when softenv starts.

SoftEnv cmd

soft add    +pkg
soft add    @pkg-grp  	# @ denoate package group
soft remove +pkg    	# yes, plus sign there, as it is indication of single package name

SoftEnv admin


Environment Modules 101 
package is typicalled software-environment-modules.rpm
RHEL5: environment-modules-3.2.9c-1
RHEL6: environment-modules-3.2.10-2
Ubuntu: environment-modules...

Note that the rpm module-init-tools is for kernel modules (lsmod, modprobe) and nothing to do with the command shell environment-module.

When the package is installed it adds a script into /etc/profile.d/modules.*sh.
source this file will initiate Environment Modules.  ie, after this, the module command will work.  
This initiation really define a function called "module", which look at the variables MODULEPATH, MODULEHOME.

because it is a function, which module and alias module returns nothing!
Instad, use declare -F to see list of defined bash fucntions.  

The function defined is shell specific (naturally) and is stored in 
eg /usr/share/Modules/init/bash

There is one binary that can be called:

/usr/share/Modules/bin/moduelcmd bash avail	# RHEL5
/usr/bin/modulecmd bash avail		 	# RHEL6, Ubuntu

this would list available modules.  the show sub-command works. but load doesn't.
must initialize module via the profile.d/ script.

To customize Environment Modules, a modulesfile can be written.  It is essentially Tcl.

no rpm for this in NixOS ??


can list all default pkg to be loaded when module starts.
however, if often need to change between diff version of a package, then don't list it to load here as everytime module command is run, .modulerc is sourced and the package that may have been unloaded would be re-loaded!!

some conflict with shell, cuz module is well embeded into bash... so moved to use .bashrc and .bash_profile. and seems like .bash_profile just source .bashrc, decided that going forward will put everything in .bashrc

Module file defintion, see github

simplified .bashrc
[[ -f /etc/profile.d/ ]] && source /etc/profile.d/
export MODULEPATH=$MODULEPATH:/opt/modulefiles/
old school .bashrc
There were some strange instances where module loading in non-interactive shell could break things.
scp? jenkin builds?
thus, a test of interactive shell evaluating $i was done.
But this seems to cause problem for sge job script not automatically loading user's modules. Thus, not favoring it anymore.

if [[ $- =~ "i" ]]; then
	# $- will have i for interactive shell when run by bash.  
	# only run module command then.  else it will spill error msg.
	export MODULEPATH=${MODULEPATH}:/usr/prog/modules/all
	module load proxy
	module load sge
	module load bedtools
	module load awscli

	# The MODULEPATH should be set in the .modulerc file located in your home directory.
	# (but then i can't easily test if on build machine that load additional module, like below, so set everything in .bashrc)
	# modules provided by bright computing
        if [[ -d /cm/shared/modulefiles ]]; then
                export MODULEPATH=/cm/shared/modulefiles:${MODULEPATH}


export MODULE_PATH=...

module available		# what can be loaded
module list			# what is already loaded
module list 2>&1 | grep aws 	# output is to stderr, so need redirect to use with grep.  no flag to make it output to stdout :(
module display ModName		# display detail of a module

module {TAB}			# list sub commands (may depend on some shell magic)

shell rc script

When does .bashrc get sourced? when is .bash_profile sourced? Apparently there was no simple answer to this questions. The details is listed in Peter Ward's flowblok. But here is the gist of the insanity:
These days, most folks have all their customization in their .bashrc, and .bash_profile just souce .bashrc:
[[ -f ~/.bashrc ]] && source ~/.bashrc
  • ssh session would source .bashrc
  • new xterm (terminal tab) does NOT source .bashrc or .bash_profile.
    IF it is set to act as "login shell", then it sources .bash_profile. Thus, having .bash_profile source .bashrc would make things more convinient :)
    Not sure if making .bashrc source /etc/profile (and thus all the /etc/profile.d/*sh env settings) is a wise idea (may cause loop or shell latency?). Thus, change xterm to act as "login shell" and setting up a barebone .bash_profile was the approach taken.

    See also

    [Doc URL]
    (cc) Tin Ho. See main page for copyright info.