extras: Discover custom extras using entrypoints

[Jomik]

Here's my quick proposal for supporting custom extras as we see popping up. The goal here is to ease user installation / removal, isolate custom code, keep klippy clean. This proposal makes use of Entry points specification, which allows python packages to make themselves discoverable once installed.

I attempted to keep the implementation minimal to allow expansion, if desired.

The developer would publish this on pypa, the user will then install the package into klippy venv ~/klippy-env/bin/pip install foo. Moonraker also supports python packages, so it can keep it up to date. A huge benefit of this, is that the custom packages can define their dependencies and optional dependencies without messing with klippy's requirements, and those will also naturally be uninstalled if the user decides to remove the installed package.

Examples:

A minimal example of a package project definition that would be discoverable with the proposal.

# pyproject.toml
[project]
name = "foo"
requires-python = ">= 3.8"

[tool.hatch.build.targets.wheel]
packages = ["src/foo"]

[project.entry-points."klippy.extras"]
foo = "foo.extra"

# src/foo/extra.py
def load_config(config):
	# Do stuff
	logging.info("Loaded foo!")

# printer.cfg
[foo]

Considerations:

• Use pkg_resources for older versions of python.

• Complexity may increase if we desire to use pkg_resources or remove the importlib_metadata compatibility backport for older versions of python. If we need to support this further back, we should consider creating a memoized function to load the module, and not expose entrypoints to load_object at all.

• Expose list of loaded components in the API - the status of each component can be queried normally.

• This could be implemented as an extra. User can add an entry_points section that enables the feature. It'll scan the entrypoint group, look for sections with that name and load them. Optionally the user could define a list to load explicitly.

Related:

• Possible Klipper “plugins” instead of macros?
• custom_component: allow to load python components natively (#6492)

[nefelim4ag]

There is no plugin or custom extras system. https://github.com/Klipper3d/klipper/pull/6492#issuecomment-2018433357

So, there should be no custom code in the extras and, as a consequence, no special code to sideload them.

The only proposed system so far is: https://klipper.discourse.group/t/new-proposal-for-klipper-extension-support/19150

No one is restricting you from hacking around; it is cool and encouraged. But in the main repo, there should be no code for a feature that does not exist.

Btw, please be aware that you need to sign off, as per point 3 in: https://github.com/Klipper3d/klipper/blob/master/docs/CONTRIBUTING.md#what-to-expect-in-a-review

Thanks

[Jomik]

There is no plugin or custom extras system. #6492 (comment)

So, there should be no custom code in the extras and, as a consequence, no special code to sideload them.

I am aware, but this is definitely a tendency, and currently made with the caveat that it's hacky and can interfere with users' klipper installation. I see no reason that we shouldn't make a small change, such as this, to better support this behavior that is seen and used by the consumers. I think it's fair to say that the only stable thing is that you get the config object where you can read the configuration of the extra in question. I don't see that adding this would be the same as promising that the extras (lookup_object) would be stable..

I hadn't seen klipper.discourse.group/t/new-proposal-for-klipper-extension-support/19150. I personally feel like my proposed solution here is better. It's less code, less to maintain and more realistic to have happen. It'll be easy to adopt for current community extras.

Of course, once an actual plugin API has been defined, this could be retired and replaced by a similar implementation, using a different group - e.g. klippy.plugins.

I am aware of the signed off - I'll do that if this is ready to be accepted, so that's pending @KevinOConnor I suppose..

[github-actions[bot]]

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.