feat: allow installation of community plugins/extensions for Klipper #330
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Is your feature request related to a problem? Please describe
It's not an issue -- I'm just wondering if you would be open to including PR that would be adding an option to install KAMP (https://github.com/kyleisah/Klipper-Adaptive-Meshing-Purging) and also as a separate PR Klippain (https://github.com/Frix-x/klippain/). Both of these are aimed at simplifying QOL on klipper.
Describe the solution you'd like
There would be an option in KIAUH that would allow installing these two (independently on each other)
Describe alternatives you've considered
There is not an easy way how to install these via moonraker and mainsail and people want generally stay away from manual setups. So KIAUH sounds as a very good option, as it's already often times used to simplify setup process
Additional information
CC @kyleisah and @Frix-x
+1, I've been reading about KAMP and it would be amazing if KIAUH supported installing and updating KAMP!
Thanks @jtrmal for the mention for Klippain. I think this issue could be renamed to "Allow install of user plugins in KIAUH" or something like that.
I see a lot of systems that could benefit from this: KAMP, Klippain, Auto Z calibration plugin (@TitusLabs ), the already included G code shell commands, etc...
I think developing this feature as a modular system would be the way to go as @Frix-x already stated correctly, so more community developed plugins/extensions/macro-configs could benefit from it. What im currently thinking of is something like an index-file where the corresponding plugin is listed with its name, github repo and "entry point", where KIAUH then can build its interface from to make it available for selection by the user. Every plugin would then need its own install script, so that it could simply be used by KIAUH as the entry-point for execution and installation to keep it simple and more importantly (for me personally) keep maintenance to each plugin developer.
Yes this is exactly what I had in mind :)
Having an install script in the plugin repo is something ok for me. In fact it's already the case in most of them, so it should be only some adaptions to make it work correctly with KIAUH.
Maybe providing a template script or something could be good to help devs integrate their repo. But this can be done later.
I'm willing to take a stab at it, if it would be acceptable, to take the weight from @th33xitus shoulders. Probably next week, if that's ok.
That's a great idea. Let me know if I need to adjust anything else for this..
@jtrmal Take your time. Im currently spending all my very limited time in completing #283 to get it shipped in the near future. And im likely not merging anything bigger into the project until #283 is merged first except bugfixes or small stuff which doesn't really touch the things i have to touch there. No idea when it's done, but probably not earlier than 2-3 weeks from now.
I guess this can be added here.
Add LED Effects for Klipper
https://github.com/dw-0/kiauh/issues/371
I guess it's also the same for Spoolman (issue #373 )
I'm sorry for being late on this. It's just my IRL existence was quite
complicated the last few months. I should have time on this soon (November
at the latest)
y.
On Fri, Sep 22, 2023 at 10:06 AM Félix Boisselier @.***>
wrote:
Take your time, there is no stress about it. It was just to link some issue that could benefit from this as well to not forget about it or let them now that some universal solution could be availabe in the future for them :)
+1 for getting spoolman in Kiauh.
+1 for getting klippain in Kiauh
+1 for KAMP and spoolman
I've been thinking how to enable this without demanding of too much continuous book-keeping from kiauh
In essence, I think we could expect each project/repo that wants to be compatible with kiauh to contain directory "kiauh" with files "install.sh" and "uninstall.sh" (or maybe just one file taking one of install/uninstall parameters).
Kiauh itself would just offer installing from a git repository (and/or local path) and then running the install script.
A little of book-keeping would be needed to support uninstall (just making note which git repos were installed or installing the projects into a specific master directory and then listing these). But kiauh already does similar stuff, so again, that might not be too hard.
I came up with an idea which im currently already implementing in v6 of kiauh and i wanted to show a small sneak peak of how the current draft is constructed
I was thinking of a new main menu option:
The option will take a user to a new submenu with a list of extensions:
Each extension itself will have another submenu where installation and removal is possible, the submenu also shows a description of the extension:
This is the visible part to the user.
Now to how a contributor could contribute a new extension to this system, which i think is quite simple and i will show it for the gcode shell command extension:
There will be an extensions folder in the project. Each extension has to be placed there. Each extension actually has to be a single python module. The module is very simple though:
Only two methods have to be implemented. Those two methods are the ones which will be called either by selecting installing or removing an extension. So the contributor has pretty much all the freedoms on how he want to accomplish that. Either through python as well, or simply call a bash script from within those install_extension or remove_extension method. Those are meant to be the so called "entry points" i had in mind in the past.
The second requirement for an extension is a metadata.json, that file is used to specify the module to load by kiauh and to provide general metadata:
KIAUH will load all extensions automatically and will dynamically build the extensions menu based on the content of the projects extensions folder.
indexof the metadata is used for sorting within the extensions menu. I wasn't sure if its really required, but i would think its good to have an option to force the sorting and do not relay on an arbitrary sequence that can occur nor on an alphabetical order. Themaintained_byshould hold the name of the contributor of that extension or the one that feels responsible if the original maintainer is not maintaining it anymore. Im not sure ifversionactually makes sense. I think i will drop that value again as i don't see an actual use in it.display_namewill hold the name that is used to show the extension name in kiauhs extension menu.descriptionholds the extension description that is shown once the user navigated to the extensions submenu.So far that is my current idea... feel free to comment on anything i proposed.