Possible Klipper "plugins" instead of macros?

Developers
28

mainly by extending the existing Klipper API server unix domain socket:

This sounds like a horrible way to write plugin code. There would be a lot of extra work involved to even get started:

  • understand how to write to a unix socket
  • some might try to use the built-in sockets library, which would introduce many more headaches, because it is very low-level
  • the api would be prone to typing mistakes which could result in bugs that are hard to find (there would be no traceback like there would be for python code that calls a nonexistent function)
    → To address those issues, someone would have to develop a separate python library that abstracts away the underlying socket api? Is this really desirable? Who would write and maintain that boilerplate code, and why would they?

Minimizing Fragmentation

As identified here, the Klipper ecosystem is increasingly dispersing. It is vital for any upcoming system to actively discourage this trend.

That is not going to happen with a limited plugin system. The proposed system would introduce too much extra work. Many of the klipper forks have features that deeply integrate into klipper and could not be implemented through a limited API.

As can be seen in the many pull requests on GitHub that are either stale or closed, it is very difficult to get anything merged into mainline klipper. A limited API would inevitably result in people requesting many more extensions to the api. My concern is that the same would happen with the limited API. Nothing will change or only very slowly, which would render it useless.

In my opinion, the best approach would be to trust the plugin developers and let them do whatever they want. The extras API is really well written, and I think with good documentation, it could be used for all the motivations mentioned in this thread.

Thinking something like a github repo with a json file:

 extensions: [
  { name: "led_control",
    repo: "https://github.com....",
    author: "You can trust me",   
    description: "Totally benine led controller"
    install_files: ["led_control.py"], //some sanity control
    deps: ["klipper >=1.0"],
    os_deps: ["numpy 1.26.2 >=1.0"],    
  }, 
  ...
 ]
}

Moonraker is already quite well established for updating external repositories (and their API is very good). I do not think it is smart to fragment the ecosystem by introducing another mechanism for updating third party code.

1 Like