Define plug-in system

[ZyanKLee]

We need some robust mechanism to control how plugins/components are installed, enabled and disabled at runtime.

[ZyanKLee]

For a first step I would suggest to symlink files instead of copying them.
We could add a folder settings/components.d and settings/scripts.d/ and components/scripts that should be enabled would be linked there.

@MiczFlor @s-martin Does that sound sane?

[s-martin]

Sounds like a good idea and if it works for Linux it should work for us 😃

[MiczFlor]

Hi @ZyanKLee @s-martin
what is the goal here? I think we need to separate local installs and their file changes from the git repo. This can be done with configuration files. Not all components will have a beautiful separation of core functionality and individual tweaks.
With symlinks, that will not make a difference. The local repo files will still be changed. Making copies decouples the two. Then it is independent.
Possibly I am missing something :) ?

[ZyanKLee]

well, using copies instead of symlinks is always an option if changes to the scripts themselves are made by the user.
But if a script is going to be used as-is, but is not part of the core-functionality, I would suggest to not use scripts, but symlinks to point at the original scripts.

But perhaps my idea went short of the goal and instead we should think about putting the configuration itself outside of the RPi-Jukebox-RFID folder. Having it at ~/.config/phoniebox/ for example would allow us to update the git repo to newer releases without caring much about anything else in the same parent directory.

[ZyanKLee]

is it feasible to also look into how components communicate with the "core"?

currently almost all RFID readers are handled by one python script, correct?
does that scale? can we improve maintainability by separating code that is specific to one device into a component and hook those components into the Reader.py based on a config variable?

same questions for buttons, displays, etc

[ZyanKLee]

should we provide a common interface for components to communicate with other parts and the core? every read and write access to the file settings/ files should in my opinion go through the core.

[s-martin]

I agree that we should think about that.

I don't know enough about Python, but we should just define an interface and let each RFID reader implement that (maybe providing the Neuftech reader as default implementation).

[s-martin]

Adressed for future3 in #1771