Introduce a plugin system that handles fine grained dependencies, and use it for applets #357
Conversation
whitequark
force-pushed
the
applet-entry-points
branch
2 times, most recently
from
98b50e6
to
64cdfde
Compare
|
@attie Note that the commits all have long descriptions, for you to read! |
`glasgow.applet.all` was an abomination. Now that it is gone, we have several new possibilities: * Out-of-tree applets is the major one. (This commit explicitly prohibits them because the API is not stable or ready for public consumption.) * Applets can now have package dependencies of their own, through their list of optional dependency groups that must be installed. This prevents any further dependency bloat of the software stack. * Applet metadata can at some point be cached to reduce load times. Loading every applet (which we still do, just in a less directly intentional way) is costly, especially on low-power systems or systems with slow disk, and the cost only grows as more applets are developed. Unfortunately, this will continue to be the case so long as `argparse` continues to be used. It might seem odd to move applet's "name" from its source code to `pyproject.toml`. This actually makes sense because it is less its name and more a handle by which it is invoked. It is likely that the handles of out-of-tree applets will collide reasonably often and in that case they will be automatically disambiguated.
As a concrete example, this (abridged) `pyproject.toml` with
a mandatory dependency on `aiohttp`:
dependencies = ["aiohttp~=3.8"]
[project.entry-points."glasgow.applet"]
audio-yamaha-opx = "glasgow.applet.audio.yamaha_opx:AudioYamahaOPxApplet"
can now be transformed into the following one with an optional
dependency on `aiohttp`:
[project.optional-dependencies]
http = ["aiohttp~=3.8"]
[project.entry-points."glasgow.applet"]
audio-yamaha-opx = "glasgow.applet.audio.yamaha_opx:AudioYamahaOPxApplet [http]"
If `aiohttp` is not installed or its version is unsatisfying, the CLI
shows a placeholder instead of the applet whose `--help` text explains
how to install the missing packages.
See GlasgowEmbedded#234.
At this point we have at least three subsystems that would benefit from a plugin mechanism based on entry points that was added to handle applets: * Applets. Duh. * Applet tools. Currently very awkwardly attached to applets even though they aren't really related. * Data loggers. `support.data_loggers` depends on `aiohttp` for a part of its functionality but because there was no way to express it, a data logger specific work around was added. This commit lays the foundation for using the same plugin system for all three.
whitequark
force-pushed
the
applet-entry-points
branch
from
64cdfde
to
30571a1
Compare
|
... one downside to this, is that we need to Certainly manageable, but might trip people up. |
you mean adding a new applet that needs some new dependency, or even when adding a new applet that doesn't need any new dependency? I haven't used the new entry-point stuff of setuptools yet, so I might be missing something here. But shouldn't the entry-point feature take care of making all the applets available, even if you change the pyproject.toml? |
Any new applet seems to require a reinstall, even if you used
With |
This is already in README by the way.
There's no really good way to do this infrastructurally even with |
|
Indeed it is... in light of this PR, how would you feel about me/you changing:
to:
|
|
Yes absolutely. |
|
Great - see #379 |
This PR introduces three related changes:
glasgow.applet.all, entry points are now used.glasgow --help, applets now specify their own dependencies, and missing dependencies are gracefully handled by replacing applet help with instructions for installing them.This is essentially the implementation of the plan outlined in #234 (comment).
It also paves way for out-of-tree applets. (At the moment they are explicitly forbidden to avoid creating a backwards compatibility hazard.)