Modules - Revision history

imported>Lkoven: Removing the quick start section. Most of those modules are obsolete on SDL6+ machines, and will cause more problems than they solved.

2015-09-25T18:39:12Z

Removing the quick start section. Most of those modules are obsolete on SDL6+ machines, and will cause more problems than they solved.

← Older revision		Revision as of 18:39, 25 September 2015
Line 1:		Line 1:
	Modules are an easy way to configure software which relies on environment variables to function, as well as maintain multiple versions of such software. The module system utilizes an executable program and aliases which call it, plus script files called 'modulefiles' which tell it what to do, and outputs shell-readable commands which are interpreted to perform the various actions needed to configure paths and environment variables for each program.		Modules are an easy way to configure software which relies on environment variables to function, as well as maintain multiple versions of such software. The module system utilizes an executable program and aliases which call it, plus script files called 'modulefiles' which tell it what to do, and outputs shell-readable commands which are interpreted to perform the various actions needed to configure paths and environment variables for each program.


	~~== Quick Start ==~~
	~~If you just want to switch in Modules and switch out having /usr/peyton/bin in your $PATH, you probably want these modules loaded:~~
	~~<tt>module load acroread ds9 firefox idl mathematica matlab openoffice thunderbird</tt>~~

	~~If you don't want some of the above modules, there's no reason to load them; conversely there's little harm in having one loaded that you don't use.~~


	== History ==		== History ==

imported>Lkoven: Added some suggested shell-fu for properly loading modules in shell startup files.

2012-06-29T18:40:09Z

Added some suggested shell-fu for properly loading modules in shell startup files.

← Older revision		Revision as of 18:40, 29 June 2012
Line 31:		Line 31:
	=== Invoking via shell startup scripts ===		=== Invoking via shell startup scripts ===
	If there's certain modules you always use, you can add the appropriate calls to your shell startup scripts; for example, adding to your ~/.bashrc <tt>module load idl intel</tt> would have the paths for IDL and the Intel compilers setup for you when you login. Once you've added these somewhere, you can later use the module init commands (such as <tt>module initadd</tt>) to edit those lines automatically; this is no different than editing the file(s) directly and adding, removing, switching or clearing the specified modules but exists for simplicity. As the manpage notes, using one of these commands will add/remove the module from every module command found in the script(s).		If there's certain modules you always use, you can add the appropriate calls to your shell startup scripts; for example, adding to your ~/.bashrc <tt>module load idl intel</tt> would have the paths for IDL and the Intel compilers setup for you when you login. Once you've added these somewhere, you can later use the module init commands (such as <tt>module initadd</tt>) to edit those lines automatically; this is no different than editing the file(s) directly and adding, removing, switching or clearing the specified modules but exists for simplicity. As the manpage notes, using one of these commands will add/remove the module from every module command found in the script(s).

			If you login to our machines from the console (that is, sitting right in front of the machine), we highly recommend using the following syntax for loading modules. This will prevent problems with some environmental variables getting clobbered by X itself. Instead of loading the modules every time your shell executes (which it does when you start an X session), it will instead only load when you have an interactive shell (which is typically the only time you want modules loaded).

			If you use bash, use the following template (modified for the modules you want loaded, of course):
			<tt>if [ "$PS1" ]; then</tt>
			<tt> module load firefox thunderbird</tt>
			<tt>fi</tt>

			If you use [t]csh, then the following template should work:
			<tt>if ( $?prompt ) then</tt>
			<tt> module load firefox thunderbird</tt>
			<tt>endif</tt>

			You will need to log out of X and back in for these changes to take full effect.

imported>Huston: Quick start

2011-12-08T16:24:00Z

Quick start

← Older revision		Revision as of 16:24, 8 December 2011
Line 1:		Line 1:
	Modules are an easy way to configure software which relies on environment variables to function, as well as maintain multiple versions of such software. The module system utilizes an executable program and aliases which call it, plus script files called 'modulefiles' which tell it what to do, and outputs shell-readable commands which are interpreted to perform the various actions needed to configure paths and environment variables for each program.		Modules are an easy way to configure software which relies on environment variables to function, as well as maintain multiple versions of such software. The module system utilizes an executable program and aliases which call it, plus script files called 'modulefiles' which tell it what to do, and outputs shell-readable commands which are interpreted to perform the various actions needed to configure paths and environment variables for each program.


			== Quick Start ==
			If you just want to switch in Modules and switch out having /usr/peyton/bin in your $PATH, you probably want these modules loaded:
			<tt>module load acroread ds9 firefox idl mathematica matlab openoffice thunderbird</tt>

			If you don't want some of the above modules, there's no reason to load them; conversely there's little harm in having one loaded that you don't use.

imported>Huston: Default versions

2011-11-01T18:28:06Z

Default versions

← Older revision		Revision as of 18:28, 1 November 2011
Line 36:		Line 36:
	For more information on the content of modulefiles and how to create them, see the manpages for <tt>module</tt> and <tt>modulefile</tt> as well as the contents of existing modules for examples.		For more information on the content of modulefiles and how to create them, see the manpages for <tt>module</tt> and <tt>modulefile</tt> as well as the contents of existing modules for examples.


			== FAQ ==
			=== Using a specific version by default ===
			If you don't want to load the latest version of something available, you can specify its version on the module load command (ie, <tt>module load idl/7.1</tt>). If you want that default to be sticky and always be the one used, you can tell module that. Create the file ~/.modulerc as such:
			#%Module
			module-version idl/7.1 default
			Now when you tell module to load idl, it will load that version by default.
	[[Category:Software]]		[[Category:Software]]
	[[Category:Unix Commands]]		[[Category:Unix Commands]]

imported>Huston at 18:26, 31 October 2011

2011-10-31T18:26:36Z

← Older revision		Revision as of 18:26, 31 October 2011
Line 1:		Line 1:
	Modules are an easy way to configure software which relies on environment variables to function, as well as maintain multiple versions of such software. The module system utilizes an executable program and aliases which call it, plus script files called 'modulefiles' which tell it what to do, and outputs shell-readable commands which are interpreted to perform the various actions needed to configure paths and environment variables for each program.		Modules are an easy way to configure software which relies on environment variables to function, as well as maintain multiple versions of such software. The module system utilizes an executable program and aliases which call it, plus script files called 'modulefiles' which tell it what to do, and outputs shell-readable commands which are interpreted to perform the various actions needed to configure paths and environment variables for each program.

	~~{{inuse\|the day to write new documentation}}~~

	== History ==		== History ==
Line 33:		Line 32:
	This will tell module to add the appropriate path to its list of modulefile directories when it first starts.		This will tell module to add the appropriate path to its list of modulefile directories when it first starts.

	Another way is to use the "use.own" module; <tt>module load use.own</tt> will load it, and create a directory called ~/privatemodules/ if it doesn't already exist. Any modules in that directory will then be added to the search paths for the module commands.		Another way is to use the "use.own" module; <tt>module load use.own</tt> will load it, and create a directory called ~/privatemodules/ if it doesn't already exist. Any modules in that directory will then be added to the search paths for the module commands. Note that it also does the same as the above 'module use' command; simply creating the directory is not sufficient for module to find its contents.

	For more information on the content of modulefiles and how to create them, see the manpages for <tt>module</tt> and <tt>modulefile</tt> as well as the contents of existing modules for examples.		For more information on the content of modulefiles and how to create them, see the manpages for <tt>module</tt> and <tt>modulefile</tt> as well as the contents of existing modules for examples.

imported>Huston at 17:29, 31 October 2011

2011-10-31T17:29:52Z

← Older revision		Revision as of 17:29, 31 October 2011
Line 1:		Line 1:
	Modules are an easy way to ~~maintain multiple~~ software ~~installations~~ which ~~rely~~ on environment variables to function.		Modules are an easy way to configure software which relies on environment variables to function, as well as maintain multiple versions of such software. The module system utilizes an executable program and aliases which call it, plus script files called 'modulefiles' which tell it what to do, and outputs shell-readable commands which are interpreted to perform the various actions needed to configure paths and environment variables for each program.

	{{inuse\|the day to write new documentation}}		{{inuse\|the day to write new documentation}}

imported>Huston: Categories

2011-10-31T17:25:41Z

imported>Huston: How to use

2011-10-31T17:23:56Z

How to use

← Older revision		Revision as of 17:23, 31 October 2011
Line 8:		Line 8:

	== What It Does ==		== What It Does ==
	The Modules package is simply a small executable program which reads in "~~module files~~", which are specially formatted TCL scripts. One writes a module file for a specific program, and tells module to read it; module will then modify your environment variables accordingly so that whatever is needed for setting up the program is done. This could mean adding a specific directory to your PATH or adding new environment variables, for example. Modules can have dependencies, and most importantly for our purposes they can have multiple versions; for example, you can have a module to setup [[IDL]] version 8.1, but still have modules for version 7.1 and 6.4. This allows for multiple versions of a program to be installed, and users can choose the one they want to be able to use or use the latest by default, all without having to modify their shell startup files (something which has been problematic for certain programs, such as the [[Intel compilers]]).		The Modules package is simply a small executable program which reads in "modulefiles", which are specially formatted TCL scripts. One writes a module file for a specific program, and tells module to read it; module will then modify your environment variables accordingly so that whatever is needed for setting up the program is done. This could mean adding a specific directory to your PATH or adding new environment variables, for example. Modules can have dependencies, and most importantly for our purposes they can have multiple versions; for example, you can have a module to setup [[IDL]] version 8.1, but still have modules for version 7.1 and 6.4. This allows for multiple versions of a program to be installed, and users can choose the one they want to be able to use or use the latest by default, all without having to modify their shell startup files (something which has been problematic for certain programs, such as the [[Intel compilers]]). We have modules setup for most of the software programs one might want to run, and others are being added as programs are installed. You can also create your own modulefiles and put them in a path so that module can find them ([[#Creating modulefiles\|see below]]).


			== How To Use ==
			=== Invoking from the command line ===
			* <tt>module help</tt> will show you the available commands
			* <tt>module load <modulefile></tt> will load the named module; <tt>module unload <modulefile></tt> will unload it
			** If you want to use a specific version, append a slash and the version number. For example, <tt>module load idl/7.1</tt> to load IDL 7.1
			** To switch module versions, instead of unloading and reloading you can use <tt>module switch idl/8.1</tt> to unload any previous IDL module and load 8.1
			* <tt>module avail</tt> will show the modules available
			* <tt>module list</tt> lists the modules currently in use
			* <tt>module help <modulefile></tt> will display any specific help for that module
			* <tt>module show <modulefile></tt> will show you what commands would be run in the shell for that module


			=== Invoking via shell startup scripts ===
			If there's certain modules you always use, you can add the appropriate calls to your shell startup scripts; for example, adding to your ~/.bashrc <tt>module load idl intel</tt> would have the paths for IDL and the Intel compilers setup for you when you login. Once you've added these somewhere, you can later use the module init commands (such as <tt>module initadd</tt>) to edit those lines automatically; this is no different than editing the file(s) directly and adding, removing, switching or clearing the specified modules but exists for simplicity. As the manpage notes, using one of these commands will add/remove the module from every module command found in the script(s).


			=== Creating modulefiles ===
			You can create your own modulefiles and tell the module system to look for them. One way to do this is by editing your ~/.modulerc file to contain the following:
			#%Module
			module use --append <your modulefile directory>
			This will tell module to add the appropriate path to its list of modulefile directories when it first starts.

			Another way is to use the "use.own" module; <tt>module load use.own</tt> will load it, and create a directory called ~/privatemodules/ if it doesn't already exist. Any modules in that directory will then be added to the search paths for the module commands.

			For more information on the content of modulefiles and how to create them, see the manpages for <tt>module</tt> and <tt>modulefile</tt> as well as the contents of existing modules for examples.

imported>Huston: History, What it does

2011-10-31T15:36:35Z

History, What it does

← Older revision		Revision as of 15:36, 31 October 2011
Line 2:		Line 2:

	{{inuse\|the day to write new documentation}}		{{inuse\|the day to write new documentation}}

			== History ==
			When disk space was costly, instead of installing all the same programs on every desktop (which can also make maintaining such software difficult) a network-shared directory called '/usr/peyton' was created which housed software that could be run on many machines. Unfortunately, /usr/peyton was used as a dumping ground for many things; New browser version available? Dump it in /usr/peyton/bin. Some software needed by a few people for their research? Dump it in /usr/peyton, and link it into /usr/peyton/bin. Over the years, /usr/peyton has become a cesspool of unused, underused and unusable programs (some of them won't run on any of the current machines, either because they're built for architectures that no longer exist or linked against libraries so old that they're no longer installed). Some programs are actively maintained, because they're segregated enough from the rest that maintenance is possible (such as [[IDL]], [[Mathematica]] and [[Firefox]]). Others however are hopelessly intertwined in the directories and can't easily be separated from the rest to update them. With this in mind, a solution was sought that would allow for centrally-maintained software to be installed on the network, while allowing for ease of updates and selection of specific program versions if needed. Initially, a directory called /usr/peyton/utils was created and a group of interested users were given access to write to it so they could maintain a repository of useful programs. Unfortunately it too started to become cumbersome and suffer similar problems, one of which was how to use the software contained therein (one had to edit environment variables to include the right path at the right location or else the wrong version would be loaded). A better solution had to be created, and using the "Modules" package seemed like the best fit.


			== What It Does ==
			The Modules package is simply a small executable program which reads in "module files", which are specially formatted TCL scripts. One writes a module file for a specific program, and tells module to read it; module will then modify your environment variables accordingly so that whatever is needed for setting up the program is done. This could mean adding a specific directory to your PATH or adding new environment variables, for example. Modules can have dependencies, and most importantly for our purposes they can have multiple versions; for example, you can have a module to setup [[IDL]] version 8.1, but still have modules for version 7.1 and 6.4. This allows for multiple versions of a program to be installed, and users can choose the one they want to be able to use or use the latest by default, all without having to modify their shell startup files (something which has been problematic for certain programs, such as the [[Intel compilers]]).

imported>Huston: Page creation

2011-10-31T14:59:54Z

Page creation

New page

Modules are an easy way to maintain multiple software installations which rely on environment variables to function.

{{inuse|the day to write new documentation}}

← Older revision		Revision as of 17:25, 31 October 2011
Line 36:		Line 36:

	For more information on the content of modulefiles and how to create them, see the manpages for <tt>module</tt> and <tt>modulefile</tt> as well as the contents of existing modules for examples.		For more information on the content of modulefiles and how to create them, see the manpages for <tt>module</tt> and <tt>modulefile</tt> as well as the contents of existing modules for examples.

			[[Category:Software]]
			[[Category:Unix Commands]]