Installing your own modules

From oldwiki.scinet.utoronto.ca
Jump to navigation Jump to search

WARNING: SciNet is in the process of replacing this wiki with a new documentation site. For current information, please go to https://docs.scinet.utoronto.ca

Note: This page deals with modules for the 'modulecmd' package. For python modules go to Installing your own Python modules. For R modules go to R Statistical Package. For local perl modules, see Perl.

Rationale

There are many potential software packages that users could potentially want. These packages have potential conflicts and dependencies. For that reason, we install packages in nonstandard locations, and use the module command to load those locations into the appropriate environment variables. The usage of the module command is explained on the Software and Libraries page.

It is possible for users to make their own collection of modules to supplement or replace the shared modules. Local user-space package and moduless are almost certainly the easiest way to deal with the wide range of packages, ensure they're up to date, and ensure that users package choices don't conflict.

With local modules, you could load modules using module load [name], just as system-wide modules. You'd have less clutter in your .bashrc, as paths can be set up in the module file, you can install and try out conflicting versions of software pages.

Another nice feature of modules is that loading them twice does not append to the paths twice. So you could re-source your .bashrc file, and not clutter up the environment variables.

How to do it

  • Type
$ module load use.own

This creates a directory $HOME/privatemodules if it doesnt exist yet, and adds it to the module path. It also make the man page for modulefile available.

  • Write module files, and put them in that directory (see below)
  • Put module load use.own in your .bashrc
  • Use module load/unload/switch/avail/whatis/list on your local modules.

Writing modulefiles

Modulefiles use commands which are an extension of the standarde scripting language Tool Command Language (tcl). The name of the modulefile becomes the name of the module used in shell commands like module load [name]. You can create a hierarchy of modules (for instance for different versions) by using subdirectories in ~/privatemodules. The module names then are the prepended by the relative path within ~/privatemodules.

In the modulefile, you can put commands to define or append environment variables and paths, express prerequirements and express conflicts.

Note that you do not have to learn much tcl to use them though, as a simple example shows. The file ~/privatemodules/somemodule could contain <source lang="bash">

  1. %Module -*- tcl -*-
    1. This is a module to access something

proc ModulesHelp { } {

       puts stderr "This module sets up access to something" 

} module-whatis "sets up access to something" prereq somethingelse conflict thatothermodule module load gcc setenv SOMEVERION 0.95 append-path PATH /home/[user]/[somedir]/bin append-path MANPATH /home/[user]/[somedir]/man append-path LD_LIBRARY_PATH /home/[user]/[somedir]/lib </source> Explanation by line:

  • line 1: identifies this as a module file
  • line 2: is a comment that explains what the module does.
  • lines 3-5: is a function definition so that module help somemodule works
  • line 6 makes module whatis somemodule work
  • line 7 expresses a prerequist that the module somethingelse should be loaded before this one.
  • line 8 expresses a conflict, i.e., if thatothermodule is loaded, this one cannot be loaded as well.
  • lines 9 through 13 are the heart of the matter. They load another module, in this case, gcc, set an environment variable, and add directories to the paths.

To learn more, simply type (if you have the use.own modules loaded):

$ man modulefile

Example

An example of creating your own module can be found on the Brian page.