-
Notifications
You must be signed in to change notification settings - Fork 70
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(color-eyre): add export-owo-colors
feature
#188
base: master
Are you sure you want to change the base?
Conversation
Sorry since I don't use features often this didn't occur to me. Would this be a breaking change for anyone with |
export-owo-colors
featureno-export-owo-colors
feature
Features are meant to be additive. Consider two crates, where the first one depends on those exports and the second one doesn't. If the second crate specifies On the other hand, an Currently there are no default features, so there's no reason someone would have I think |
Always reexporting `owo-colors` causes rust-analzyer's code completion to fill with many auto-use suggestions for the `owo-colors::OwoColorize` trait. This feature allows users to opt-out of reexporting `owo-colors`.
ok the feature is now additive.
I'm not sure what you mean. There is both |
no-export-owo-colors
featureexport-owo-colors
feature
Ah, my bad. I guess I looked in the wrong place for feature documentation |
Agreed, Personally, I rarely export dependency crates unless they are extensively used in the external API, as the user can easily bring their own, rather than having two ways to import it. This is made somewhat easier with RA recent checks for |
Reexporting
owo-colors
causes rust-analzyer's code completion to fill with many auto-use suggestions for theowo-colors::OwoColorize
trait.This feature allows users to opt-out of reexporting
owo-colors
.see eyre-rs/color-eyre#109