Merge ~jugmac00/lpci:use-pluggy-for-plugins into lpci:main
Status: | Merged |
---|---|
Merge reported by: | Jürgen Gmach |
Merged at revision: | 74aa47d9bb72fbe6889174c0f6d4351b4dc9ddee |
Proposed branch: | ~jugmac00/lpci:use-pluggy-for-plugins |
Merge into: | lpci:main |
Diff against target: |
413 lines (+257/-4) 17 files modified
.mypy.ini (+1/-2) docs/index.rst (+1/-0) docs/plugins.rst (+22/-0) lpcraft/commands/run.py (+6/-2) lpcraft/config.py (+1/-0) lpcraft/plugin/__init__.py (+6/-0) lpcraft/plugin/hookspecs.py (+13/-0) lpcraft/plugin/lib.py (+25/-0) lpcraft/plugin/manager.py (+23/-0) lpcraft/plugin/tests/__init__.py (+0/-0) lpcraft/plugin/tests/test_builtin_plugins.py (+112/-0) lpcraft/plugins/__init__.py (+5/-0) lpcraft/plugins/tox.py (+17/-0) lpcraft/tests/test_config.py (+21/-0) requirements.in (+1/-0) requirements.txt (+2/-0) setup.cfg (+1/-0) |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Colin Watson (community) | Approve | ||
Review via email:
|
Commit message
Introduce pluggy to manage internal and external plugins
Description of the change
- pluggy has not been type annotated yet
- the documentation will be extended once all hooks are defined/created; e.g. tox uses a sphinx plugin to auto-document the hooks (this will be a new MP)
The internal hook `lpcraft_
This "mismatch" could be solved by:
- creating two different hooks, e.g. `_lpcraft_
- using a class as namespace, which I did, so the internal hook can access the job configuration via `self.config`
- just pass the job configuration to all hooks, and ignore the information where it is not needed; that is what pytest does a lot; I did not use this approach as the signature/interface of the hook would be more complex than needed
What I'm not sure I understand here is how this is going to hook into the configuration file syntax. The spec says that `.launchpad.yaml` can say something like `plugin: tox` to cause the `tox` plugin, and only the `tox` plugin, to be used for the current build. This implementation seems to load and execute all discoverable plugins, which certainly makes sense for some plugin systems but it's not what we're looking for here.
This might be something you're going to address in a later branch; could you elaborate on your plans?