Activating/installing notification media plugins: we must choose one of the many ways to do it

[hmpf]

Currently, the backend code includes two media plugins: "email" and "sms" (sms-via-email). After the notification loading restructure They are installed by having their full dotted paths added to the django setting MEDIA_PLUGINS, and only the email-plugin is in the supplied example settings-files. (If plugins were django apps instead they would be added to INSTALLED_APPS in the settings.)

In order to use both of these, it is necessary to set up Django's email system, the plugins just handles email addresses and phone numbers.

With other types of plugins, like teams, slack, discord, you create a webhook at the destination which is all you need to send to that destination (but what you send depends on the type of destination of course.) There is no need whatsoever to change django settings.

Some fundamental questions that needs to be answered for any plugin system is:

1. Should it be possible to use 3rd party plugins from source code not under the control of the main project?
2. If yes to 1, should the main project come with some plugins included, and which ones?
3. If yes to 2, are the bundled plugins obligatory or can they be replaced by a 3rd party plugin?

As of now, the newest procedure to activate a plugin is to add it to MEDIA_PLUGINS since no 3rd party plugins are complete yet. Adding it will update the Media-table and the entry in the Media-table makes it possible for a user to make a DestinationConfig for media.

Three methods for allowing plugins is detailed in https://packaging.python.org/en/latest/guides/creating-and-discovering-plugins/. I think the first method, using a naming convention, is unpythonic, clunky and ugly, and I will not consider it any further. I have tested method two, namespace packages, and know for a fact that they are clunky, ugly and likely to break things and not play well with others. The third method, packaging entrypoints, means installing a plugin will also activate it, unless we add a manual activation step via the Media-table. A fourth possibility is having plugins be Django apps, a fifth is continuing with what we have today, a sixth is using a plugin-framework.

1. Naming convention
2. Namespace package
3. Package entrypoint
4. Django app
5. A homebrew system like what we already have
6. A 3rd party plugin framework

We should pick one.

[hmpf]

See https://github.com/Uninett/Argus/issues/187#issuecomment-1106198831, what we pick here can be reused for issue tracker plugins.

[hmpf]

1. Should it be possible to use 3rd party plugins from source code not under the control of the main project?

Why bother with plugins at all if this is not one of the important end goals?

2. If yes to 1, should the main project come with some plugins included, and which ones?

If we bundle any, I'd say just the email one.

3. If yes to 2, are the bundled plugins obligatory or can they be replaced by a 3rd party plugin?

I'd say they all need to be replaceable. (That also makes for cleaner code).

[hmpf]

As for how to do it, I would prefer 3, Package entrypoint, but would not mind too much 4, Django app. Django apps allows for using django templates stored as files on disk, which is what the email and sms-plugins use today, but it is perfectly possible to use django templates not stored as files but as strings. The experimental msteams plugin does not use django templates at all since an msteams "card" is built up via code.