So I currently have some commits here on a local fork which I wanted to invest some time in, but I want to know if merging would be on the table otherwise I'd just be wasting my time.
In short I'd go for a more modular approach where packages are loose blocks from the system-level blocks like updating, rebooting, networking etc:
Have a folder packages/<package_name> which resides separate packages (just like a package repository like apt does) which you install from. For example: packages/glances/ would have the files necessary to install https://github.com/nicolargo/glances
Makes for a better approach since installing a full lamp stack is not what everyone wants. Instead of installing apache, mysql, php etc. one might want to switch out apache for nginx but would then need an uninstall block and nginx install block.
These package blocks could have a dependencies property which would check for dependencies installed on the fs and if they are not present abort the install. For example glances (mentioned above) needs python-dev installed from apt before glances can install from pip (and of course needs pip too). It would check is python-dev & pip are installed and abort if not present.
Aborted installs can go to a log which user can visit on first/second boot to see failed installs.
Instead of having a sidebar full of blocks in the UI of PiBakery itself users could pick between a system blocks menu or a package blocks menu, the latter would be searchable.
So I currently have some commits here on a local fork which I wanted to invest some time in, but I want to know if merging would be on the table otherwise I'd just be wasting my time.
In short I'd go for a more modular approach where packages are loose blocks from the system-level blocks like updating, rebooting, networking etc:
packages/<package_name>
which resides separate packages (just like a package repository like apt does) which you install from. For example:packages/glances/
would have the files necessary to install https://github.com/nicolargo/glances