[systemd-devel] Future of systemd Python module

[David Strauss]

On Tue, Jan 22, 2013 at 1:40 PM, Lennart Poettering
<lennart at poettering.net> 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
   | david at davidstrauss.net
   | +1 512 577 5827 [mobile]