Klipper3d / klipper

Klipper is a 3d-printer firmware
GNU General Public License v3.0
8.98k stars 5.17k forks source link

[WIP] custom_component: allow to load python components natively #6492

Open ayufan opened 4 months ago

ayufan commented 4 months ago

It become quite common for Klipper users to create custom components and create a dance to symlink them into extras folder. This PR provides a first class support for custom_components that can be loaded as part of printer.cfg:

  1. First: Every custom component to be used to be declared as custom_component, component name to load, and path where the component is loaded.
  2. The component will be lazily loaded on a first use.
  3. The custom component will track how many times the component was used, and expose git information if component is repository.
  4. It is responsibility of the custom component author to ensure compatibility with Klipper.
  5. The custom_component load module is only compatible with Python 3.5+, for older versions there's no support for custom_component.

printer.cfg

[custom_component hello_world]
path: ~/my_klipper/hello_world.py

[hello_world]

hello_world.py

class HelloWorld:
    def __init__(self, config):
        self.printer = config.get_printer()

        # Register commands
        self.gcode = self.printer.lookup_object('gcode')
        self.gcode.register_command("HELLO_WORLD", self.cmd_HELLO_WORLD)

    def cmd_HELLO_WORLD(self, gcmd):
        gcmd.respond_info("Hello World")

def load_config(config):
    return HelloWorld(config)

GET /printer/objects/query?custom_component%20hello_world

{
    "result": {
        "eventtime": 2422.219077722,
        "status": {
            "custom_component hello_world": {
                "path": "~/my_klipper/hello_world.py",
                "git_info": {
                    "version": "fc11477a-dirty",
                    "file_status": [],
                    "branch": "master",
                    "remote": "origin",
                    "url": "git@github.com:ayufan/printer-klipper-data.git"
                },
                "used": 1
            }
        }
    }
}

Considerations

  1. It might be desired to run klipper in secure mode that disables custom_component function.

References

  1. https://github.com/moggieuk/ERCF-Software-V3/blob/master/install.sh#L101
  2. https://github.com/beacon3d/beacon_klipper/blob/master/install.sh#L22
  3. https://esphome.io/components/external_components
github-actions[bot] commented 3 months ago

Thank you for your contribution to Klipper. Unfortunately, a reviewer has not assigned themselves to this GitHub Pull Request. All Pull Requests are reviewed before merging, and a reviewer will need to volunteer. Further information is available at: https://www.klipper3d.org/CONTRIBUTING.html

There are some steps that you can take now:

  1. Perform a self-review of your Pull Request by following the steps at: https://www.klipper3d.org/CONTRIBUTING.html#what-to-expect-in-a-review If you have completed a self-review, be sure to state the results of that self-review explicitly in the Pull Request comments. A reviewer is more likely to participate if the bulk of a review has already been completed.
  2. Consider opening a topic on the Klipper Discourse server to discuss this work. The Discourse server is a good place to discuss development ideas and to engage users interested in testing. Reviewers are more likely to prioritize Pull Requests with an active community of users.
  3. Consider helping out reviewers by reviewing other Klipper Pull Requests. Taking the time to perform a careful and detailed review of others work is appreciated. Regular contributors are more likely to prioritize the contributions of other regular contributors.

Unfortunately, if a reviewer does not assign themselves to this GitHub Pull Request then it will be automatically closed. If this happens, then it is a good idea to move further discussion to the Klipper Discourse server. Reviewers can reach out on that forum to let you know if they are interested and when they are available.

Best regards, ~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.

nelsongraca commented 3 months ago

@ayufan I see this has been untouched for some time now, are you planning to complete this? I think this would be a good addition to klipper

ayufan commented 3 months ago

I did not get a feedback. I would love to get this merged, if there is agreement on this. So, if get preliminary approval will finish it.

On Sat, 23 Mar 2024 at 11:28, Nelson Graça @.***> wrote:

@ayufan https://github.com/ayufan I see this has been untouched for some time now, are you planning to complete this? I think this would be a good addition to klipper

— Reply to this email directly, view it on GitHub https://github.com/Klipper3d/klipper/pull/6492#issuecomment-2016441569, or unsubscribe https://github.com/notifications/unsubscribe-auth/AASOSQKZRCLYIYPIS2QWF5TYZVKMTAVCNFSM6AAAAABDKIMGWGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJWGQ2DCNJWHE . You are receiving this because you were mentioned.Message ID: @.***>

nelsongraca commented 3 months ago

I would get it ready to be useable and merged into master, without being marked as a draft, ensure the checks pass, self review etc, I don't think anyone will look into something marked as a draft

KevinOConnor commented 3 months ago

I started a discussion on something similar at https://klipper.discourse.group/t/possible-klipper-plugins-instead-of-macros/9819 .

It would be important for me that a "plugin" system have a well understood and stable API. Otherwise, I fear "plugins" could inadvertently destabilize other parts of Klipper, and minor changes in Klipper could inadvertently break 3rd-party code. The Klipper "extras" system was never intended as a "plugin" system, and I don't think it meets those requirements.

Cheers, -Kevin

nelsongraca commented 3 months ago

I started a discussion on something similar at https://klipper.discourse.group/t/possible-klipper-plugins-instead-of-macros/9819 .

Thank you for making me aware of if will have a look and drop my feedback, I'm interested in helping in a solution

ayufan commented 2 months ago

It would be important for me that a "plugin" system have a well understood and stable API. Otherwise, I fear "plugins" could inadvertently destabilize other parts of Klipper, and minor changes in Klipper could inadvertently break 3rd-party code. The Klipper "extras" system was never intended as a "plugin" system, and I don't think it meets those requirements.

Yeah, this is always a problem. However, there's not a good solution. There are ways to maintain out of system information about the compatibility with Klipper, and also making Klipper more aware of what is happening.

The problem today is that the are vendors, and users that simply already have to mess with extras, which is likely even worse.

@KevinOConnor As a good example you can see this working pretty well in Home Assistant and ESPHome ecosystem, where there's a big repository of built-in components, but equally big of external components. Quality of external varies, but I doubt people would drop those things at random. And if they do, they would be themselves to blame.