Make features optional

[lnicola]

This crate is nifty, but it has quite a lot of dependencies. For example, a lot of apps might be interested only in the notify functionality, which presumably doesn't need external crates.

[lucab]

Thanks a lot for the feedback! I think there are indeed a couple of simple dependencies that could be dropped (e.g. try_or), if you want to open a PR that would be welcome.

However I don't want to start introducing cargo-features for each specific sub-areas. That would introduce a matrix of cases for API-maintenance and testing. All methods so far are covering the main systemd API and they are non-optional there, and this crate it's just sticking to that direction.

[lnicola]

Please consider this in the context of https://raphlinus.github.io/rust/2019/08/21/rust-bloat.html. In agersant/polaris#40 I added libsystemd-rs as a dependency to a medium-sized apps and it came with 15 new transitive dependencies. From those I believe that only one (try_or) is actually used.

It's fair if you don't want to introduce feature gates for extra functionality, though. Perhaps there's room for a systemd-notify crate that only offers support for startup notifications. Why? Because systemd is really common, and a lot of not-systemd-specific applications that run as daemons would have legitimate interest in supporting it better. These have no need for extra libsystemd functionality.

[lnicola]

I've published https://crates.io/crates/sd-notify, which offers a workaround for this.

[lucab]

That makes sense to me. Is there anything I can do to make parallel maintenance easier? I don't plan to touch this module in the short term, except for an async version at some point when the dust settles on the rest of the ecosystem.

[lnicola]

No, I don't think so. My implementation is mostly inspired from yours (so you could use it as a dependency, but.. meh). I'm more worried about how neither of them conforms to what the C library does, like credential passing and increasing the send buffer size.