One friction point from being able to use Anodized in a library crate is how runtime behavior feature flags interact with feature unification in Cargo.
There are 2 problems with this:
Problem 1
As a crate author I may want to allow the library consumer to specify the runtime behavior.
I could do this by creating feature flags on my own crate that are propagated to the anodized crate.
However this is a lot of manual feature plumbing for crate authors
Problem 2
The more pressing issue is that due to runtime behavior's being mutually exclusive, this prevents me from depending on multiple crates that have opted for different runtime behaviors. Cargo feature unification will activate both features causing a complication error.
Proposed Solution
Provide a library feature that is functionally the same as runtime-no-check but that will defer its behavior to any active runtime a feature.
This would allow crate authors to use the library feature and library consumers to specify their desire behavior in their bin crate.
Tradeoff a notable trade off here is that we limited to a single behavior for all crates in the project. You would not be able to panic for one crate and print for another
Alternatives
An alternative to this would be to have an interface similar to tracing_subscriber where you would initialize a global configuration like
anodized::runtime::init(anodized::RuntimeBehavior::Panic)
# or
anodized::runtime::init_with_config(Config::builder()
.crate("foo", anodized::RuntimeBehavior::Panic)
.crate("bar", anodized::RuntimeBehavior::Print)
.build())This would offer more control over behavior that crate features, but comes with a lot more complexity and places new users could make mistakes.
One friction point from being able to use Anodized in a library crate is how runtime behavior feature flags interact with feature unification in Cargo.
There are 2 problems with this:
Problem 1
As a crate author I may want to allow the library consumer to specify the runtime behavior.
I could do this by creating feature flags on my own crate that are propagated to the anodized crate.
However this is a lot of manual feature plumbing for crate authors
Problem 2
The more pressing issue is that due to runtime behavior's being mutually exclusive, this prevents me from depending on multiple crates that have opted for different runtime behaviors. Cargo feature unification will activate both features causing a complication error.
Proposed Solution
Provide a
libraryfeature that is functionally the same asruntime-no-checkbut that will defer its behavior to any active runtime a feature.This would allow crate authors to use the
libraryfeature and library consumers to specify their desire behavior in their bin crate.Tradeoff a notable trade off here is that we limited to a single behavior for all crates in the project. You would not be able to panic for one crate and print for another
Alternatives
An alternative to this would be to have an interface similar to
tracing_subscriberwhere you would initialize a global configuration likeThis would offer more control over behavior that crate features, but comes with a lot more complexity and places new users could make mistakes.