refactor: Using submodules as features #460
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Following the discussion in #342, this PR tries to get an initial MVP for (potentially) splitting into subcrates in the future.
The important change is in
Cargo.toml
: each submodule becomes a feature, and they are all enabled by default. In turn, all the dependencies are optional, and I mapped what deps are used for each submodule in the correspondent feature.The main advantage of this approach is not making maintenance harder (it is still all one crate, with one version). It is a bit weird to have all the deps as optional, but I don't think that is too bad?
I also keep all new submodule features in the
default
feature set, so current users won't see a difference. In the future it might be worth adding docs/instructions to guide people in two directions:bio
in an application, using the defaultbio = "0.x"
dependency is fine; you might want to tune to reduce your build times, but it won't make it harder for new users to userust-bio
.bio = { version = "0.x", default-features = false, features = ["io"] }"
if you only use theio
features.I also added extra CI checks for running tests for each feature/submodule individually, to guarantee they stay working (and minimally depend on each other).
Points for discussion
phylogeny
feature was not tested in CI, and a docstring test was actually broken. I added a CI check, and since it is inside theio
submodule I also made it activate theio
feature if used.Future work
serde
into a feature too, but I didn't want to change the code too muchnewtype_derive
andcustom_derive
are unmaintained (last releases are from many years ago), maybe find alternatives?