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@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@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.
- 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
- 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.
- 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.
- 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
- 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