'Plugin' loader

[Enderboi]

I find adding this little bit of code very useful for Badge Development - so putting it out there in case someone else does.

Why for Vogons-sake did I write this, instead of using the application framework?

Well, this little hack allows you to add chunks of persistent code to your badge, while retaining the functionality of the boot application (eg. conf schedule, or any future functionality like secure messaging). Not only does it make it easy to extend or add functionality to an existing application (simply upload a file into 'plugins/). And if you are testing chunks of random code or want to try someone elses code snippet, this method is both easily revertible but still persistent (if you want it to be) without modifying too much :)

Notes:

• You can Enable or Disable the plugin functionality, by toggling the configuration/main.py flag
• On boot, this will try and load all files within the 'plugins/' directory

[marcmerlin]

great, I was considering something similar. I see you are loading other code, but I didn't see anything that runs initialise() or run() in that imported code. How does that part work?

[Enderboi]

At the moment, the plugin just calls it's own init functions at the bottom of the file:
https://github.com/Enderboi/aiko_engine_mp/blob/master/plugins/handshake.py

I'm hoping to extend this with some UI to enable/disable plugins in the future - at that point it would be a more selective load process, so each plugin may need explicit constructor and destructor functions. Left as an exercise to the reader for now tho!

[garthk]

I hacked up another plugin system in another branch, not realising @Enderboi'd already raised a PR—my comments above were on his commit. I'm sorry for the toe-treading. A couple paragraphs from its README might still be appropriate for this version:

Plugins aren't the same as applications. In particular: we only want to be running one application at a time. To get a little RFC2119, the application MAY assume it has sole control of what's shown on the OLED displays, and MAY assume any touch sensor or push buttons are for it to handle. Eventually, their initialise function might get a matching uninitialise, or we might get very clever and remove their handlers automatically.

Plugins, on the other hand, MUST co-operate with each other, MUST NOT assume they control the displays or inputs, and SHOULD work together. We'll eventually run into conflicts we can't resolve without being able to disable specific plugins, but let's see how long we can last.

The not-applications part riffs off comments by @geekscape in Spectrum and the BOF chat; sorry in advance if I got your take wrong there Andy.

Differences between the systems, documentation aside:

• Added support for directory modules as well as single files
• Switched to initialise functions to match the rest of the framework
• Excluded plugins named initialise to avoid a namespace clash after import plugins
• Took out the global parameter: the plugin system always runs at boot
• Added implicit parameters to disable plugins

Other handy changes:

• Started some documentation
• Updated the deployment scripts

Steal what you want. :)