-
Notifications
You must be signed in to change notification settings - Fork 93
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
plugin framework #4106
Comments
TBD (should use one if there is one, obviously)
That's probably the best strategy IMO. We definitely need plugins to be able to alter the config, and having plugin-specific config sections would be clean and clear. Is there a case for allowing them to alter existing config too, if necessary? (If so, the existing config should be a built-in plugin?).
Don't see why not.
Yes, probably.
TBD |
BTW my thoughts:
Yes, at least all "scheduler" plugins get a All "install" plugins get a
Yes
Yes see (2). |
Using a framework is a good idea, just need to find one to suit, changing from question into investigation. Note we are currently using entry-points as a light-weight plugin interface. It has been suggested that it would be a good idea to pick an approach that doesn't mandate the plugins to be However, see also #3780 which would potentially overcome this issue by allowing plugins to be |
We have made our first tentative steps with plugins. I think this is a positive change both to the internal structure of Cylc and to its future with lots of exciting possibilities to tap down the line.
For now we have started implementing plugins using Python entry points. These do the job fairly well, they are easy to write and easy to discover, however, they are not easy to configure.
All plugins will be run if they are installed, the
main loop plugins
get around this by adding their own configuration[scheduler][main loop]plugins
which can be added to on the CLI. Each main loop plugin also gets assigned a section in the config. This does the job but we really wouldn't want to go through this for each and every plugin.Some things the current approach is lacking:
[scheduler][plugins][<plugin name>]
.We should consider adopting a plugin framework like pluggy.
A good example of
pluggy
in action ispytest
, however, Cylc is different from this (any many other good plugin examples) in thatcylc
is not a single command, it is many and not all plugins are relevant to all functionalities. We don't want to waste time in eachcylc
invocation loading plugins that we don't need (e.g. you don't need to load the main loop plugins in order to runcylc validate
). Cylc, being distributed has the problem that plugins might not even be installed in all places.Something along the lines of this would be nice, however, would load more than we would like for each command invocation (must import the plugin and the things the plugin imports):
Something like this would be nice, however, the whole plugin would have to be loaded for each
cylc
invocation. (That might just be the price of opening up the config to modification, especially if we allow specifying defaults in the global configuration. Note that at present all plugins are imported on use thanks to the entry point mechanism.)Questions:
[scheduler][plugin][<plugin name>]
?[scheduler]
plugins, do we need an[install][plugins]
section too?The text was updated successfully, but these errors were encountered: