Package management


As several different versions of the ACCESS utilities are in active use it is helpful for us to have an organised way of managing multiple installation versions of tools and libraries. These instructions mirror the setup used in the general NCI system.

Modules


Create a module directory under /projects/access/Modules/modulefiles named after the package. There shouldn't be any top-level module files here. Users should add this directory to their $MODULEPATH environment variable.

Create a .version file in this directory to specify the default version, containing
#%Module
set ModulesVersion $version
replacing $version with either the package version number or git/svn for files downloaded directly from a repository.

The expectation is that versions given a specific version number will remain unchanged, while repository versions are potentially in active development & subject to change.

Create a module file in the new directory, with the same name as was specified in the .version file. A good basis is the iris/git module, which checks for the existence of default paths given an installation prefix and adds them to the environment.

If the package depends on external python packages also create a pythonenv module file alongside the project file. Again look to iris/pythonenv for an example, this is used to load python packages common to multiple package versions.

Installation


Actual packages should be installed under /data/projects/access/apps/$package/$version, using the usual bin, include, lib subdirectories if there's no compelling reason not to. If the package is a python library it should be installed into a subdirectory named python, this will be added to $PYTHONPATH by the module file.

Python environment


Options for Python environment:
  • Global python
    • Potential for conflicts with ACCESS packages
    • Easier to use with user packages
    • Provides an existing set of modules
  • ACCESS project virtualenv
  • Individual module virtualenv
    • Duplication of resources
    • Conflicts when multiple packages are loaded

Options for Python packages:
  • Module combined into the virtualenv
  • Modules for individual packages
    • More complex directory structure
    • Doesn't reproduce packages for multiple virtualenvs
    • Only loads what's necessary



Deprecation


Packages no longer receiving support should be marked as deprecated by adding an error message to that version's modulefile, along with the date that deprecation occurred. Packages should be left in a deprecated state for enough time for people to upgrade scripts etc., but may be removed after some time has passed.

Installation Notes


Please keep a record of how packages were installed, so that they can be reproduced for new releases