Re: Status of dbus-python

Hi Simon,
thanks for a thorough explanation.

I unskillfully phrased the part
> and can't make use of sd-bus at the moment
I meant I can't easily port it to the board I'm currently
working on.

Am grateful for that now, for it resulted in the
clearest clarification of the relation between
the three libraries. Tnx :)

Be Well,
Alan



On Tue, Mar 27, 2018 at 3:40 PM, Simon McVittie <[email protected]> wrote:
> On Tue, 27 Mar 2018 at 14:58:07 +0200, Alan Martinovic wrote:
>> is it known what is the status of d-bus python?
>
> It is semi-maintained but not really recommended. It has design flaws
> that cannot be fixed without losing its most important feature ("is
> compatible with dbus-python").
>
>> The package on PyPI is pretty old (1.2.4)
>
> Oh, I should update that at some point. The primary download location
> is freedesktop.org, and dbus-python is the only thing I maintain that
> has releases on PyPI, so I never remember how to update them...
>
> Source releases are canonically available here:
> https://dbus.freedesktop.org/releases/dbus-python/
> (and when I get round to updating PyPI, it'll just get a copy of the latest
> one of those)
>
> Because dbus-python is a Python wrapper around libdbus, an OS-level C
> library, you might be better off using a binary release of dbus-python
> from your OS distribution (Debian, Ubuntu, Fedora or equivalent).
> dbus-python is not a fast-moving project, and any version from the last
> couple of years should be fine.
>
>> and basically suggest not to use it:
>>
>> > dbus-python might not be the best D-Bus binding for you
>> > to use.
>
> I wrote that text and I stand by it.
>
> It might be the best D-Bus binding for you to use, or it might not.
> Please make an informed decision on its merits, and don't just go for
> dbus-python because it's the one that has the "dbus" name.
>
>> However the repo seems to be pretty much alive
>
> The changes I made in January were to decouple it from dbus-glib, which
> nobody should be using. It has no new features and few new bug fixes.
>
>> The GDBus seems more difficult to start with
>
> I'd still recommend either GDBus via gi.repository.Gio, or some
> convenience layer over it, as a better basis for a general-purpose
> D-Bus implementation.
>
>> and can't make use of sd-bus at the moment
>
> It sounds as though you might be confused about the status of GDBus and
> sd-bus. A GDBus-based library will probably never use sd-bus, for
> approximately the same reasons that wget doesn't use libcurl: they are
> different implementations of the same idea (but you can talk D-Bus to
> any service with both, the same way you can download from any web server
> with either wget or curl).
>
> libdbus, GDBus and sd-bus are three independent C implementations of
> the D-Bus protocol, with different designs, different priorities and
> different design trade-offs. They interoperate (you can write a client
> with any of them and talk to a server that uses any other) but their C
> APIs are incompatible. A Python binding for one of them is very unlikely
> to be compatible with a Python binding for a different one, because the
> author of a Python binding will have chosen a suitable C library and a
> suitable API to match their own priorities.
>
> A GDBus client can communicate with systemd via D-Bus: because all
> D-Bus implementations are interoperable, you don't have to use sd-bus
> to communicate with systemd.
>
>     smcv
> _______________________________________________
> dbus mailing list
> [email protected]
> https://lists.freedesktop.org/mailman/listinfo/dbus
_______________________________________________
dbus mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dbus