implement basic plugin system #202
Conversation
|
What's the use case for this? This seems like it's going to make the control flow more confusing if all of a sudden we're calling both Python -> C and C -> Python. Are there use cases that can't be covered by e.g. gobject signals? And what specific plugins are we talking about? Could those be baked in as e.g. compile time options? I'm a bit uncertain about pulling in libpeas in particular - basically the project's goal can't really be achieved, because you can only have one GC'd language per process, so you have C/Vala/Rust and at most one of Python/JS/golang etc. |
|
@cgwalters one of main plugins will be subscription manager (which will be entirely in C). Yes, any of plugins can be backed by compile-time options. My goal was mainly to achieve plugin system for C and Python. |
|
Would it not be easier to have subscription manager support as a compile time option instead? |
|
@kalev that was only example, but basically we want all plugins (which we have in dnf) to become part of the libdnf (e.g. needs_restarting/tracer, snapper, etc.) |
ignatenkobrain
force-pushed
the
wip/ignatenko/plugins
branch
2 times, most recently
from
035f1c0
to
8c5d3a4
Compare
ignatenkobrain
changed the title
|
retest this please |
ignatenkobrain
force-pushed
the
wip/ignatenko/plugins
branch
7 times, most recently
from
6c9a0ba
to
650e0b1
Compare
ignatenkobrain
force-pushed
the
wip/ignatenko/plugins
branch
from
f57890b
to
1233c05
Compare
ignatenkobrain
changed the title
|
@j-mracek, any ideas why testcase fails? |
| g_autoptr(PeasEngine) engine = peas_engine_get_default (); | ||
|
|
||
| /* Enable Python 3 plugins */ | ||
| peas_engine_enable_loader (engine, "python3"); |
There was a problem hiding this comment.
But this is exactly what I don't want for rpm-ostree. Why can't python plugins stay as dnf plugins?
|
test this please |
|
Another reason not to have plugins right now is that the API is far from stable. So my vote is still to bake in subscription-manager as a compile time option, and conditionally evaluate the set of dnf plugins for migration into C. Some other ones like tracer honestly should most likely stay as dnf plugins, given that I doubt we're going to use them for PackageKit or rpm-ostree. |
|
We don't say libdnf plugin API is stable now. It will be formed together with the rest of API. The high level vision is to have most parts from DNF in libdnf. DNF would be just Python wrapper around libdnf with DNF CLI input/output handling. In best case the libdnf plugin API should be close to current DNF API. All plugins would be handled in lindnf core. Plugins extending DNF output like tracer could have set special demand so it would run in dnf, tdnf and microdnf only. Does that make sense? For example, this way even SWDB could be implemented just as a plugin... |
ignatenkobrain
force-pushed
the
wip/ignatenko/plugins
branch
from
834baf2
to
aa7df06
Compare
Signed-off-by: Igor Gnatenko <ignatenko@redhat.com>
Signed-off-by: Igor Gnatenko <ignatenko@redhat.com>
ignatenkobrain
force-pushed
the
wip/ignatenko/plugins
branch
from
aa7df06
to
04a51ce
Compare
I think that would be a dangerous mistake, unless you'd like to support both the dnf yumdb and swdb. |
|
I'd be more OK with doing this initially if the plugin system itself is a build time option. Then I could just disable it for rpm-ostree. |
|
☔ The latest upstream changes (presumably 632545b) made this pull request unmergeable. Please resolve the merge conflicts. |
Signed-off-by: Igor Gnatenko ignatenko@redhat.com