owo_colors re-export makes code-completion hard to use (IntelliJ Rust) about color-eyre

[chklauser]

Hey, thanks for looking into this 🙂

I totally agree that re-exporting makes sense when the types show up in the public API, and indeed they do (Theme). In that case, the optional feature should really include all of the APIs (e.g., custom themes) that expose the owo_colors types to avoid crate version mismatches.

But it seems awkward to carve out such a feature. I don't really want to impose changes on color-eyre just because some editor can't deal with a blanket impl. I only opened the issue because I mistakenly thought that owo_colors was not used in the public API 😓

=> I have filed an issue with IntelliJ Rust intellij-rust/intellij-rust#8901

[yaahc]

1. Is there a reason why color-eyre has to re-export owo_colors? As far as I can tell, no type of owo_colors shows up in the public API => users who wish to use owo_colors could define their own dependency.

the reasoning behind re-exporting owo-colors is because we use some of their types in our public API, and if you depend on multiple versions of the same crate you can end up with confusing errors around incompatible types. I try to avoid this by always re-exporting all dependencies which are part of my crate's public API so that users don't have to import those crates separately and can instead name the re-exported version and be 100% sure they're going to get the correct version that is used in our API.

2. Would it maybe be possible to put the re-export behind a cargo feature? (Totally fine if it's enabled by default). 👉 Sketch commit of what that could look like (excl. docs)

I'm totally fine with merging this as a work around, though I do feel like the best fix would be upstream in IntelliJ Rust. I feel like maybe this is an indicator that certain cases of trait methods that aren't in scope shouldn't be completed, in this case because the trait impl has a blanket impl<T: Sized> OwoColorize for T {}. In practice owo-colors is not usable in all of these situations because the bounds that cause compilation errors are on the types that it produces, which will end up not implementing Display and thus doing nothing other than getting in the way. I'd be surprised if there are any traits that have a blanket impl for all T where it makes sense to complete them still even when the trait isn't in scope.

I think that color-eyre is a really cool project 😄 It makes it easy to create CLI tools that communicate information effectively when it's arguably most useful: when things don't quite go according to plan 😉 Thanks for sharing it with the world 😄👍

Thank you 😊