Adding support for a users extras directory

I thought I would post something here before starting work on it.

It seems like a lot of users are uncomfortable making custom host modules, because they have to put them in the extras folder. The reasons i’ve heard are varied. Some don’t like messing with what they consider ‘core’ klipper, others don’t like it, because it can’t easily be added to their archive/backup/repo of the config directory.

loading extras is confined to a very small section of the code base.

what are peoples feelings/thoughts on adding a setting to the printer config section that would allow users to specify a directory for their own modules?

3 Likes

IMO this would be perfect. Preferably multiple directories could be specified. This would help a lot to simplify the setup for users of not-yet-supported printers (like mine), when they need to use modules from different repositories. Currently, I had to clone the entire Klipper repo just to add modules and direct the users to install Klipper from there.

2 Likes

That’s a good example and use case, I haven’t personally encountered.

I think this would be a worthwhile addition. I’m frankly surprised Klipper doesn’t use the standard Python (sys.path) mechanism…

1 Like

I like the idea.
Also, It would be nice to have a folder for user kinematics. Something like:

contrib/extras/
contrib/kinematics/

Maybe Moonraker could be configured to keep up to date some third party modules.

1 Like

It’s easy for an error in an “extras” module to cause the klippy process to become unstable. For example, things like using blocking IO, using global variables, calling a core function from a background thread, and similar can all cause hard to debug errors.

As such, I don’t consider an “extras” module to be a “plugin” - instead I view it as part of the “core Klipper code”.

Obviously, people can customize the code and run the code they wish. However, I think it should be clear that they are customizing the code and are running custom code.

So, FWIW, I’d be leery of adding a change that blurs that distinction to the main Klipper repository.

Cheers,
-Kevin

You might not consider the modules to be plugins, but a lot of people are using the extras folder like they are.

in my humble opinion the documentation even indirectly suggests that’s what they are.
https://www.klipper3d.org/Code_Overview.html#adding-a-host-module

The Klippy host code has a dynamic module loading capability. If a config section named “[my_module]” is found in the printer config file then the software will automatically attempt to load the python module klippy/extras/my_module.py . This module system is the preferred method for adding new functionality to Klipper.

I’ve seen people have the very issues you are concerned about, because they grabbed a module off of github, discord, etc and dropped in in the extras folder and made the appropriate changes to their config, without really knowing what they are doing.

A very simple way to alleviate potential issues would be to have a list of validated/sanctioned/blessed modules hardcoded into to klippy.py, and only load them out of the extras folder.

Then for the people who are developing, experimenting, testing, etc a seperate folder could be used. You could call it user_plugins, user_modules, or anything other name that makes it blatantly obvious what they are. If they get load, you could push a message to the log, and and some kind of warning message to the console, to make users aware they are on their own.

such a setup, might even help get new modules more thoroughly tested before they potentially get incorporated into the core, because it lowers the fear factor and risk of messing with the core.

4 Likes