[PD] environment modules for Pd

Charles Z Henry czhenry at gmail.com
Mon Jan 19 00:22:38 CET 2015


Modules helps isolate software(s) from each other.  it's mainly so I
don't break what is currently working when I'm messing around..

now if I can just keep from breaking the modules (sudden dread... nah
never happen)

On Sun, Jan 18, 2015 at 3:25 PM, Jonathan Wilkes <jancsika at yahoo.com> wrote:
> Can't you just symlink to various Pd-Vanilla/Pd-double versions that you've
> compiled?  That way you don't have to install anything system-wide.
>
> -Jonathan
>
>
> On Sunday, January 18, 2015 3:26 PM, Charles Z Henry <czhenry at gmail.com>
> wrote:
>
>
> 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 at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>



More information about the Pd-list mailing list