Double down on hooks, remove app plugin in favour of individual hooks for individual capabilities
Goals
- Separate out device integration from more specific app functionality integration
- Allow app wrappers to initialize via configuration, rather than needing scripting to register against the previous app interface
- Allow a single Kolibri instance to run in both 'app mode' and not 'app mode' depending on the browsing context rather than whether the app plugin is enabled - this will allow more flexible usage on Windows and Linux where there is a need to be both an app and a server.
- Lean into Kolibri hooks for all configuration
Summary
- Cleans up deprecated abstractproperty decorators
- Adds a hook for adding plugins to the KolibriProcessBus
- Adds a class property to KolibriHook to check if any hooks are registered against it
- Deletes the app plugin and migrates all the capabilities registration to use KolibriHooks
- Creates two device hooks for GetOSUser and CheckMeteredConnection
- Creates a content hook for ShareFile
- Updates capability checking to be done in individual SPAs rather than a global app capabilities utility
- Reimplements the share file functionality that had been inadvertently removed in 0.15.x
- Creates a new development plugin that enables all app functionality with dummy handlers, and logs the initialization URL on startup
- Automatically runs with this plugin for development
References
Depends on #12874 to allow specifying an extra python path for the development plugin Needed to support https://github.com/learningequality/kolibri-installer-android/issues/197
Reviewer guidance
I feel like leaning into the hooks makes sense to have a single way to customize Kolibri - is there anything about this that makes this less obvious?
By separating out the specific functionality that is more 'app' versus 'device' oriented, it has made each implementation a little more bespoke - but it seems sensible to me that metered connection checking doesn't have to be exclusive to app mode - is the minor added fiddliness an issue?
With the addition of the server hooks, we could also turn ZeroConf integration into a plugin, which would allow us to turn it off slightly more elegantly - and in a swappable way so that on Android we can provide the multicast implementation via built in Android mechanisms. The other configuration that feels like could benefit from being pluggable is the restart hooks - should we push more into plugins/hooks rather than relying on options.py?
Build Artifacts
| Asset type | Download link |
|---|---|
| PEX file | kolibri-0.19.0b2.dev0_git.101.g835d213c.pex |
| Windows Installer (EXE) | kolibri-0.19.0b2.dev0+git.101.g835d213c-windows-setup-unsigned.exe |
| Debian Package | kolibri_0.19.0b2.dev0+git.101.g835d213c-0ubuntu1_all.deb |
| Mac Installer (DMG) | kolibri-0.19.0b2.dev0+git.101.g835d213c.dmg |
| Android Package (APK) | kolibri-0.19.0b2.dev0+git.101.g835d213c-0.1.6-debug.apk |
| Raspberry Pi Image | kolibri-pi-image-0.19.0b2.dev0+git.101.g835d213c.zip |
| TAR file | kolibri-0.19.0b2.dev0+git.101.g835d213c.tar.gz |
| WHL file | kolibri-0.19.0b2.dev0+git.101.g835d213c-py2.py3-none-any.whl |
Updated, rebased, and force pushed.