Split up into multiple subcrates

[swsnr]

Hey @lucab,

this crate became quite big; it has accumulated a few different features already, and got quite a few dependencies.

How about splitting it up into multiple subcrates which allows downstream users to pick only parts of this crate to reduce the amount of dependencies?

Specifically I'd very much like to move the contents of logging into a separate crate to avoid pulling in e.g. nom just for writing to the systemd journal, and we could perhaps also join forces with the author of sd_notify or just reexport sd_notify.

What do you think?

[lucab]

Good question.
My personal feedback is nuanced: some changes are net-positive, some others come with too much of a drawback.

Here is an initial assorted list of thoughts:

• from experience with other projects, splitting into multiple subcrates is quite a mess to handle. In particular, version bumping / tagging / publishing gets into a state where it's too easy to make tragic mistakes.
• if the goal is to slice the library into smaller bits, we can put each module behind a feature flag. That same flag would also gate the required dependencies. The tradeoff is increased CI complexity, and more cargo twists.
• removing dependencies is not a sane goal by itself, but some selective decoupling can be done.
• the "no dependencies" approach mostly applies to projects in their beginning phase (or personal/toy one). For larger development, I'm grateful that serde, libc, nix, nom & co. can be easily used, and that cargo manages all of that.
• trading shared dependencies for more hand-written bugs and local unsafe landmines is generally not a good idea. We do all rely and benefit from a strong ecosystem of fundamental and safe libraries.

[swsnr]

Oh, we do have quite different opinions indeed 🙈

I'm careful with dependencies, and I'd trade a dependency the size of nix for half a dozen trivial unsafe calls any time 🙂 I'd not try to get rid of serde or nom for sure, but if I can get rid of nix with some trivial libc wrappers I think it's a positive change 🙂

I believe that reducing dependencies helps; if I use but a very small subset of a dependency (as we do with nix here) I tend to prefer copying selective parts over bringing in a huge amount of unused code, which nonetheless adds to build times. I hate to pay for transitive dependencies of parts I don't even use (e.g. nom and serde if all I use is logging.rs 🙂 ).

I also tend to believe that splitting into a workspace of loosly coupled (I mean the logging module doesn't really have any relation to the sysusers stuff, does it?) subcrates is much simpler than feature-guarding individual modules. Dependencies are pretty easy to understand in Rust, but cargo features lead to an explosion of possible build states and outcomes which is hard to manage in my experience.

I think we'll probably need to agree to disagree here 🙈 If you like we can close this issue; I'll probably just copy the relevant parts of this crate to my projects then (which is totally fine with me, after all the journal interface is pretty much set in stone and I don't expect much changes there 🙂 )

[swsnr]

@lucab I'm closing this issue, because I don't think we'll be doing it 😄 and I'm just clearing out my issues list 😇