Switch from dbus-rs to zbus

[zeenix]

While there are certain cases where dbus-rs makes more sense than zbus, with most of the Rust ecosystem using zbus, means that users of this crate easily end up depending on both dbus-rs and zbus. This is the case for Zed right now and how I noticed this.

Would a PR to switch to zbus be welcome?

[Seeker14491]

The PR that introduced our dependency on dbus had originally used zbus, but the fact that zbus pulled in a lot of dependencies was cited as the reason to use the dbus crate instead. But I see that zbus has surpassed dbus in popularity, so it seems less of a consideration if apps are already commonly pulling in zbus (also the default in opener is to statically link dbus anyways, so users might easily end up with the bloat and compile time of having both). And of course the fact zbus is pure Rust is appreciated as it might make cross compilation easier, etc.

So in summary I do think moving to zbus is reasonable.

[zeenix]

The PR that introduced our dependency on dbus had originally used zbus, but the fact that zbus pulled in a lot of dependencies was cited as the reason to use the dbus crate instead.

Ah that's fair. We did remove a lot of deps in the last year or so and I intend to drop even more and make more of them optional in the future release. I just did the work and will create PR in a moment. I also took the liberty of enabling LTO for the release builds of opener-bin. Here are the changes wrt to build times (of dev profile) and binary sizes on my machine:

• cold build time: 8s -> 15s.
• release binary size: 1.3M -> 3.1M

I know that's a huge diff in terms of % but IMHO an increase of <10 seconds for a cold build and <2 MB size increase is not super bad, especially given that I'm 100% certain I can decrease this in zbus 6.0.

But I see that zbus has surpassed dbus in popularity, so it seems less of a consideration if apps are already commonly pulling in zbus (also the default in opener is to statically link dbus anyways, so users might easily end up with the bloat and compile time of having both).

Exactly my point. :) For simple requirements like of this crate, dbus-rs is typically not a bad choice really but when you need more than a few lines of D-Bus handling, the more ergonomic API of zbus becomes well worth the dependency tree.

And of course the fact zbus is pure Rust is appreciated as it might make cross compilation easier, etc.

Not "might", it really does help a lot there. 😉 I've had folks switching over from dbus to zbus and complaining about cross-compilation failing to only realise later that they forgot to remove dbus-rs from the Cargo.toml. :)

So in summary I do think moving to zbus is reasonable.

👍

[Seeker14491]

Thanks for the PR. opener-bin is just used for testing and debugging this library, so no need to worry about it.

[zeenix]

Thanks for the PR.

You're welcome. 👍 When this is included in a release (no hurry at all), I'll make sure to get Zed folks to update.

[Seeker14491]

I've made a release.

[zeenix]

I've made a release.

Cool. I'll provide the update PR to Zed this week.

[zeenix]

I've made a release.

Cool. I'll provide the update PR to Zed this week.

By "Zed", I meant mdbook cause Zed doesn't use opener directly. :) I did that now. Interestingly the PR removes the dbus dep but doesn't add zbus dep. I guess that's cause the dbus-vendored feature was unconditionally the default.

[Seeker14491]

That sounded strange, so I did some investigation.

• mdbook depended on opener v0.7.2, but it didn't enable opener's reveal feature. opener only pulled in the dbus dependency when that reveal feature was enabled. However, opener v0.7.0 had a bug that caused dbus to be pulled in unconditionally. So when mdbook updated to that version, it pulled in dbus. mdbook later updated to newer versions of opener that had fixed the bug, but Cargo's specifics regarding handling of optional dependencies in the lockfile meant the dbus crates remained in mdbook's lockfile despite not actually being in the build anymore.
• The Zed editor itself does not depend on mdbook; it's only used by the docs_preprocessor crate in the Zed repo which is a preprocessor for Zed's documentation. Zed itself already uses zbus exclusively.