On Tue, Jan 22, 2013 at 1:40 PM, Lennart Poettering <[email protected]> wrote: > We > had the question of creating C libraries for wrapping D-Bus APIs in > GNOME upstream a few years ago, and we all came to the conclusion that > instead of writing those we should rather make the D-Bus python glue > nicer. The result of that was that GLib's "gdbus" stuff is nowadays > substantially easier to use then the old libdbus bindings. A similar > story is probably not only true for C but for Python, too. > > Simple 1:1 mappings of D-Bus/Python calls add a substantial amount of > code and are really hard to keep updated. They add another layer we have > to take care for and that complicates our stack. > > I mean, I am not up-to-date what the state of D-Bus API glue for Python > is, but I am tempted to say that the preferred way to contact the > systemd bus APIs is probably by directly using the D-Bus API glue for > Python rather than any module in between.
That's absolutely the case. We should ensure our actual D-Bus APIs are clean for the sake of languages like Ruby, too. We'd actually get more out of Ruby bindings for service management than Python, as both Chef and Puppet are Ruby-based. Python bindings would support the less popular BCFG2 (which I used to be a maintainer for) and Ansible. Juju is also Python-based, but it is mostly on Ubuntu and, to a lesser extent, Mac OS X -- neither of which would benefit from deeper systemd integration right now. I think our scripting language and D-Bus support will be solid when we could, at least theoretically, rewrite systemctl and journalctl in Python or Ruby. -- David Strauss | [email protected] | +1 512 577 5827 [mobile] _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
