-
Notifications
You must be signed in to change notification settings - Fork 139
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
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.) |
035f1c0
to
8c5d3a4
Compare
retest this please |
6c9a0ba
to
650e0b1
Compare
f57890b
to
1233c05
Compare
@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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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... |
834baf2
to
aa7df06
Compare
Signed-off-by: Igor Gnatenko <ignatenko@redhat.com>
Signed-off-by: Igor Gnatenko <ignatenko@redhat.com>
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