Hi list,

It's been awhile since I've posted anything useful--I have badly
broken my desktop's pd install and am setting up a new pd install on
my laptop today.  I've run into problems with having too many
compilations of pd and installing them system-wide.  I realized that I
needed to have different installations for development and some
standard compilations of vanilla and extended--plus wanting to try out
pd-l2ork and pd-double precision that I've never tried before.  Also,
it's good to be able to have many versions of the same software for
regression testing and documenting bugs.

That's the motivation for now setting up "environment modules",
sometimes also called "Unix modules", keeping multiple instances of
software and choosing among them which one will be added to the path
in the current shell.  So, this is a discussion of how to get modules
working effectively for Pd.

1.  Install
Deb/Ubuntu:
apt-get install environment-modules
RH/Fedora:
yum install environment-modules

(I leave it up to you to tell me what you do in OSX or arch).

To test, start a new terminal and run
module avail

If you receive the "module: command not found" error, then check your
terminal preferences.  Modules depend on having a "login" shell to
properly run startup scripts.

Modules use environment variables to keep track of the module search
path and loaded modules.  The "module" command itself is an alias for
"modulecmd $SHELL $@" (paraphrased).  To see the full list of module
related variables, run:
env | grep -i module

2.  Location of module files
as non-root user, run
module load use.own

This will create a directory ~/privatemodules directory and the file
"null" in it.  "module avail" will list "null" in your privatemodules
directory.  You may replace "privatemodules" with a symlink to some
other location if you wish.  Each time you want to load modules from
~/privatemodules, you have to run "module load use.own" first.

as root, you can edit /usr/share/modules/init/.modulespath and add any
path you like, like an NFS location.  You can also just place modules
into one of the default search paths, like
/etc/environment-modules/modules or /usr/share/modules/modulefiles.

Note: you may need to add or edit some things as root anyway.  Test
your installation for this tab-completion error in bash.  Type "module
load <tab>-<tab>" and see what happens.
In Ubuntu 14.04, the /etc/bash_completion.d/modules script has this line:
/usr/share/modules/3.2.10/bin/modulecmd bash -t avail 2>&
However, there is no such file.  You can edit the file and change that
path to /usr/bin/modulecmd or create a symlink to /usr/bin/modulecmd
as /usr/share/modules/3.2.10/bin/modulecmd.  Neither solution will
save you from re-encountering this bug next time you update
environment-modules.

digression: In ye olde cluster mill, this is how we're handling the
massive pileup of software: the OS install includes only development
software and infrastructure using packages (for platform stability and
consistency at the expense of performance).  All applications and
high-performance libraries are installed as a non-root user into
locations in NFS.  This lets us maintain arbitrary versions of
software without collisions or replacement, to be used at the users'
discretion.  In the past, I had re-written parts of a custom
application called "mpi-selector" (from Cisco) to let users setup
their environment... and later found out there was already a 20-year
old solution named "modules".  I edit the .modulespath file and
include a location in NFS--there's no sync issues and no outdated
files on the nodes, because everything needed for applications is in
NFS.  If a user needs to run a previous version at a date in the
future to reproduce results or compare changes, this can be done
easily and without admin assistance.

3.  What to put in a module file:

If you've already installed modules, run
man modulefile
http here: http://linux.die.net/man/4/modulefile

The first line of a module should be:
#%Module

The primary commands you'll need are
prepend-path
setenv
set-alias

Note that modules use tcl, with specific commands that get translated
according to which shell you're currently using.  You can't run
arbitrary code to setup Pd in the module file (please prove me wrong
:D ).  If you have your own "run-pd.sh" script, that differs for each
version of Pd you want to use, you can still manage this well with an
alias and environment variables.

4.  Using defaults
For sh/bash, edit ~/.profile or ~/.bash_profile, or for csh/tcsh, edit
~/.cshrc, and add
module load use.own (for non-root user privileges as mentioned above)
module load pd-0.45.4

To load a different version, you can unload the current version
(tab-completion will list loaded modules) and then load a new one,
such as
module unload pd-0.45.4
module load pd-extended-0.43.4

5.  Pure Data specific concerns (please provide feedback for anything
I may overlook---or simpler ways to accomplish things)

the HOME directory:
Each version of pd you're using may have its own home directory and
have its own .pdsettings file.
For this I make a tree of version-specific home directories such as:
mkdir -p /home/chenry/pd_HOME/pd-0.45.4

separate installation directories:
Then, I make an installation directory for it:
mkdir /home/chenry/pd-0.45.4

and compile using --prefix=/home/chenry/pd-0.45.4

My modules file for pd-0.45.4 is:

#%Module
setenv PD_HOME /home/chenry/pd_HOME/pd-0.45.4
setenv PD_BIN /home/chenry/pd-0.45.4/bin
prepend-path PATH /home/chenry/pd-0.45.4/bin
prepend-path LD_LIBRARY_PATH /home/chenry/pd-0.45.4/lib
set-alias pd {HOME=$PD_HOME $PD_BIN/pd $*}
set-alias pd-gui.tcl {HOME=$PD_HOME $PD_BIN/pd-gui.tcl $*}
set-alias pdsend {HOME=$PD_HOME $PD_BIN/pdsend $*}
set-alias pdreceive {HOME=$PD_HOME $PD_BIN/pdreceive $*}

I think this script might be a bit longer than it needs to be, but not
by much.  Any feedback is most welcome.
I found that I needed the PD_BIN variable in my "set-alias" commands.
I think I managed to cause a stack overflow with the alias pd as
{HOME=$PD_HOME pd $*}

You can check the aliased commands with the "type" command, ex. "type pd"

Also, the alias will not apply when you run pd in a debugger, such as
"strace pd".  You will need to expand the alias yourself and place the
variable declaration at the front as:
HOME=$PD_HOME strace $PD_BIN/pd

I also considered having HOME set to the PD_HOME variable globally,
which would avoid aliases.  If you did, defaults in ~/.profile would
be a little annoying.  Also, changes to other programs ~/. files would
be discarded when changing pd versions.

If you are not setting any defaults, it's fine to just set HOME in
your module files, knowing that you will be running only Pd after
running "module load" (and maybe jackd as well, if you have different
settings for jack you'd like to apply to each pd version).  In which
case, a working module file becomes just this short:

#%Module
setenv HOME /home/chenry/pd_HOME/pd-0.45.4
prepend-path PATH /home/chenry/pd-0.45.4/bin
prepend-path LD_LIBRARY_PATH /home/chenry/pd-0.45.4/lib

Chuck

_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list