mirror of
https://github.com/freedombox/FreedomBox.git
synced 2026-01-28 08:03:36 +00:00
39 lines
1.7 KiB
Markdown
39 lines
1.7 KiB
Markdown
# 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 _().
|