Help with splitting library best practices

help
1

Hi!

I'm working on a library that getting quite large with lots of included data, but when using the library in projects I'm noticing that the library takes quite a bit to compile. To solve this I would like to split the library in a way so that if you don't need everything you don't need to compile everything with the added benefit that you can pick only the parts that you need, but I'm not sure what the best approach for this is.

How I see it there are two ways to do this: either split the library through feature flags or split the library into multiple crates.

Splitting the library using feature flags has the advantage of keeping it one thing on crates.io and keeps it simple, but after some testing I'm not noticing that much improvement in compilation time even if I were to only enable some small part of the library and nothing else.

Splitting the library into different crates has the advantage of allowing the user to just pick a single crate if they don't need anything else, but that would require that some of the crates require the others as dependencies and I'm not experienced with how that would work with versioning. For example in the following example:

  • Installed crate A which depends on crate B with version 1.0.0
  • Manually also install crate B with version 1.1.0

I'm not sure what kind of issues would arise from this. Also this would mean that I would have three crates on crates.io which feels a bit excessive.

To put all of the above into two concrete questions:

  1. Is it possible to improve the compile time through feature flags and if so what are some things to take into account?
  2. Does splitting the library into multiple create issues with how versions are handled?

I did found this topic but it hasn't received a reply.

Any input on this greatly appriciated. Thanks in advance!

2

Nothing, cargo takes care of semver-incompatible dependencies. As long as you follow semver, you can't break things with this.

Why though? People have dozens of crates each.

With everything else equal, I would not create separate crates, only for reasons of convenience. I hate it, both as a library author and as a user, when a conceptually coherent piece of functionality forces me to maintain or depend on several small crates instead of just giving it to me all at once.

3

Thanks for your input!

4

One idea I also toyed with was having the current splitting it up and then adding feature flags to the current crate that would reexport the underlying sub-crates. That way you could still have 'one' crate that has all while still also allowing people to pick and choose if they so wish.

5

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.