feat: re-export everything from eyre

[deckstose]

color-eyre is just a thin wrapper around eyre and should behave the same. This includes the API. For this purpose all items that are publicly available in eyre should be available without another submodule from color-eyre.

[deckstose]

Discussion started here.

[deckstose]

There are some unrelated changes like this in doc comments as I formatted the code with rustfmt's format_doc_in_comments option to fix ordering of use statements. If you don't mind I would like to keep them, but it's no issue to remove them or split them in a different PR.

[LeoniePhiline]

Fantastic. The new imports as seen in the diff are the API I had always wished for.

I would love to see this merged, but I would also like to see more discussion about a possible merge:

• Rename eyre to eyre-core.

  • Make it an implementation detail.
  • Discourage direct use of eyre-core.

• Rename color-eyre to eyre.

  • Make it the canonical public API.
  • Do not leak internal abstraction such as an internal eyre-core library (see this PR).

• Rename color-spantrace to eyre-spantrace.

• Deprecate and archive simple-eyre.

• Deprecate and archive stable-eyre.

• Deprecate and archive jane-eyre, or at least very clearly mark it as a joke / pun crate.

It may not be useful to keep eyre-core and eyre-spantrace as workspace crate libraries:

I would like to recommend changing crate eyre-core into mod core and changing crate eyre-spantrace into #[cfg(feature = "capture-spantrace")] mod spantrace.

—

(Follow up):

Gated by #[cfg(feature = "capture-spantrace")], eyre should also re-export tracing_error. (Or at least it’s ErrorLayer required by the user for subscriber setup.)

The tracing_error dependency declaration should disable the default feature traced-error.

[nik-rev]

I would like to recommend changing crate eyre-core into mod core

Does this prevent people from creating custom eyre handlers, without bringing in color-eyre's dependencies?

I'd like to keep the opportunity for other crates to develop their own custom eyre hook (I'm working on one myself)

Currently on the main branch, that looks like this:

---
[dependencies]
eyre = "0.6"
color-eyre = "0.6"
---

use color_eyre::Result;

fn main() -> Result  {
    color_eyre::install();
    Ok(())
}

With a custom hook, not from color-eyre:

---
[dependencies]
eyre = "0.6"
fancy-panic = { version = "0.1", features = ["eyre"] }
---

use eyre::Result;

fn main() -> Result {
    fancy_eyre::install();
    Ok(())
}

With your proposed changes, usage of the colored hook is simplified:

---
[dependencies]
eyre = "1.0"
---

use eyre::Result;

fn main() -> Result  {
    eyre::install();
    Ok(())
}

Let's assume that the color feature is required, and enabled by default.

Then to use an external handler, you have to disable the default feature, and you also have to enable features that are enabled by default:

---
[dependencies]
eyre = { version = "0.6", default-features = false, features = ["track-caller"] }
fancy-panic = { version = "0.1", features = ["eyre"] }
---

use eyre::Result;

fn main() -> Result {
    fancy_eyre::install();
    Ok(())
}

Alternatively, if we keep the eyre-core crate, the API looks like this:

---
[dependencies]
eyre-core = "1.0"
fancy-panic = { version = "0.1", features = ["eyre"] }
---

use eyre_core::Result;

fn main() -> Result {
    fancy_eyre::install();
    Ok(())
}

Which I think is actually worse, because we want to consider eyre_core an implementation detail, and for the optimal user experience we want to continue allowing:

use eyre::prelude::*;

Instead of:

use eyre_core::prelude::*;

Using a different report handler shouldn't require renaming every module where eyre types are imported.

This basically forces the user to do a crate rename:

eyre = { package = "eyre-core", version = "1.0" }
fancy-panic = { version = "0.1", features = ["eyre"] }

Which leaks implementation details as well (user shouldn't have to know about eyre-core. Also, installing a custom eyre handler should only require adding a fancy-panic dependency, you shouldn't have to edit the eyre dep).

So the tradeoffs are:

• Using eyre with color-eyre becomes easier, because you dont need a separate dependency
• Assuming color-eyre becomes just a feature, using eyre with an external reporter becomes harder, because you have to disable the default feature, and enable other default features
• Assuming we have eyre-core, implementation details will be leaked when the user wants to install an eyre handler from a different crate

My proposal is to do what you said, but put the color-eyre part behind a feature which is disabled by default:

---
[dependencies]
eyre = { version = "1.0", features = ["color"] }
---

use eyre::Result;

fn main() -> Result  {
    eyre::install();
    Ok(())
}

Which makes using an external hook easier:

---
[dependencies]
eyre = "1.0"
fancy-panic = { version = "0.1", features = ["eyre"] }
---

use eyre::Result;

fn main() -> Result {
    fancy_eyre::install();
    Ok(())
}

This seems like a fair compromise. However, it does make using the blessed color-eyre handler case harder to use, so if that's not a tradeoff you are willing to do, then I will understand.