Module names and module naming conventions
==========================================

The modulefiles contain commands that change the user's environment to
make an application or library available to a user.  So loading a modulefile
named gcc/7.1 should hopefully make the programs Gnu Compiler
Collection (i.e. gcc, gfortran and g++ compilers) available to a user.

So the ``gcc/7.1`` module is a file named either 7.1 or 7.1.lua depending
on whether the commands are written in TCL or Lua respectively and
this file is in the ``gcc`` directory.

To see a more complete module layout, let's assume your site has
has a MODULEPATH set to::

   /apps/modulefiles/Core:/apps/modulefiles/Other

And the directory layout from /apps/modulefiles is::

   $ cd /apps/modulefiles; tree -a
   .
   ├── Core
   │   ├── A
   │   │   ├── 1.0
   │   │   └── 2.0.lua
   │   ├── gcc
   │   │   ├── 5.4
   │   │   └── 7.1.lua
   │   └── StdEnv.lua
   └── Other
       ├── C
       │   ├── 3.3.lua
       │   └── 3.4.lua
       └── D
           └── 4.0.lua

In the above structure there are 8 modulefiles.  So the 5
modulefiles under Core are: A/1.0, A/2.0, gcc/5.4, gcc/7.1 and
StdEnv.  Note that Lmod's name of a modulefile doesn't include the
.lua extension.  Also note that both A and gcc have two versions where
as StdEnv has a name with no version.

fullName == sn/version
~~~~~~~~~~~~~~~~~~~~~~

The fullName of a modulefile is complete name which is made of two
parts: sn and version.  The sn is the shortname and represents the
minumum name that can be used to specify a module.  So for the
``gcc/7.1`` modulefile.  The fullName is ``gcc/7.1`` and the sn is
``gcc`` and the version is ``7.1``.  This naming convention is known
as NAME/VERSION and is abbreviated N/V.  There are two more complicated
naming schemes known as Category/Name/Version (a.k.a. C/N/V) and
Name/Version/Version (a.k.a N/V/V).  In all three naming schemes, a
modulefile has a fullName which is split into sn / version.  The split
between the sn and version will be different depending on which naming
scheme is used.  Sometimes the version doesn't exist like for StdEnv
module. In this case the fullName is the same as the sn.

In next section :ref:`modulepath-label`, we explain how a Lmod takes
an ``sn`` and determines which modulefile to load.  But in short, Lmod
picks the marked default or if there is no default then Lmod picks the
"highest" version.

Special Names for modulefiles
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

If the version has a leading dot then this modulefile is hidden.  That
is, it can be loaded but it won't be shown by ``module avail``. If the
sn name has a leading dot, such as ``.X`` then every version of this
module will be hidden.   So ``.X/1.0`` is hidden and so is ``Y/.2.0``.

Because of the way that Lmod passes information between module command
invocations, a modulefile **CANNOT** have two or more leading
underscores. So naming a modulefile ``_A/1.0`` is acceptable but
having two underscore such as ``__B/1.0`` is not!

Module Naming scheme: Category/Name/Version (C/N/V)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Sites may wish to group similar modules into categories.  For example,
all the biology packages grouped together, like bowtie and tophat
packages be named: ``bio/bowtie/3.4`` or ``bio/tophat/2.7``.  When the
fullName is ``bio/bowtie/3.4`` then the sn for is ``bio/bowtie`` and the
version is ``3.4``.

Sites should think carefully about chosing to using C/N/V.  This can
make it easier for users to know which modules provide say physics, 
chemistry or biology applications but it does lead to great deal more
typing of which tab completion provided by the bash or zsh shells can
only do so much.

Sites can have meta-module inside a category. A meta-module is a
module that has no version.  For example, suppose you have the
following C/N/V modulefile structure:: 

     $ cd /apps/modulefiles/Other; tree -a 
     .    
     └── bio
         ├── bowtie
         │   └── 3.1
         ├── genomics.lua
         └── tophat
             └── 7.2

In this case there are three modules ``bio/bowtie/3.1``,
``bio/tophat/7.2``. The ``bio/genomic`` module is a meta module where
the fullName is the same as the sn and it has no version.

The rule that Lmod uses to determine which modules are meta modules
and which have a version is the following.  If a file is in a
directory that has other sub-directories (other than `.` and `..`),
the file is a meta-module.  So the genomic.lua file is part of the sn
for bio/genomics because the genomics.lua file is in a sub-directory
that has the directories ``bowtie`` and ``tophat``.

Sites can mix N/V and C/N/V layouts, Lmod will be able to decide the
sn and versions by walking directory tree. In general, the fullName,
will be divided into directories names to become the sn and the
version will be the file.  So for the fullName ``bio/tophat/7.2`` the
directores bio and tophat become the sn, ``bio/tophat`` and the
version is ``7.2``.

Lmod supports as many directory levels as site likes.  For example, a
site could have a modulefile named ``A/B/C/D/1.1`` where the sn name
is ``A/B/C/D`` and the version is ``1.1``.


Module Naming scheme: Name/Version/Version (N/V/V)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

A site many wish to have directories has part of the version. This
could be used to have 32 or 64 bit versions of the same package. So for
example a site might wish to have a modules named ``acme/32/4.2`` and
``acme/64/4.2`` where sn is ``acme`` and the versions are ``32/4.2``
and ``64/4.2``.

By default, Lmod assumes that the version is just the file, so lmod
needs to be told where the sn / version split is.  This can be done by
creating an empty ``.version`` or ``.modulerc`` file where a site wants the
split to be.  For the above example, the following layout make
``acme`` be the sn::

   $ tree -a
   .
   └── acme
       ├── .version
       ├── 32
       │   └── 4.2
       └── 64
           └── 4.2

because there is a .version at the same level as the 32 and 64
directories.  With the .version file, the fullName is ``acme/64/4.2``
and the sn is ``acme`` and the version ``64/4.2``.  If the .version
file was removed then the sn would be ``acme/64`` and the version
would be ``4.2``.

Sites are can name modules with as many directories as they like.  For
example a site can have a module named::

   mpi/mpich/64/3.1/048

If there is an empty file at ``mpi/mpich/.version`` then the sn
would be ``mpi/mpich`` and the version would be ``64/3.1/048``.  

