# Modules

Almost all of the front end's functionality is contained in small,
separate modules that reside in the directory tree beneath
`plinth/modules`.  Some are installed by default, some are
required for operation, and some are entirely optional.

## Installing and Loading Modules

Eventually, the goal is for module to be separate Debian package so
installation is as simple as `aptitude install freedombox-foo`.  As an
intermediate step, we'll start scripting module installation.  But
until then, we can install them manually.

A Plinth module is a Django application with some additional Plinth
specific extensions.  To enable a module, create a file containing its
Python module path into `data/etc/plinth/modules-enabled/`.  During
installation, this file will be copied to
`/etc/plinth/modules-enabled/`.  The file in `/etc` will be read during
normal execution of Plinth.  The file in `data/etc/` in the source code
directory will be used when running Plinth under the run-without-install
mode.  Plinth will read the module path from the file in one of these
paths during start-up and configure Django to use it as a Django
application.  With this approach, you can install your Plinth module
anywhere on the system and use it in Plinth (just like in Django).

TODO: automatically prune dead links to clear out old module installs.
This is something the install scripts should do.

## Coding Practices for Modules

All the
[coding practices for hacking on the front end](#hacking_code_practices)
also apply to modules.  In addition, I try to stick to the other
practices listed in this section.

* Every module should `from gettext import gettext as _` and wrap
displayed strings with _().