Avoid anyhow dependency

[jennydaman]

Hello,

I am wondering whether it'd be possible for a future version of reqwest_middleware to leave out the dependency on anyhow::Error.

reqwest-middleware/reqwest-middleware/src/error.rs

Line 10 in 8d40b60

Middleware(#[from] anyhow::Error),

• As a "library-level" crate, we should use more specific error enums if possible.
• In the community there is some shift in preferences and recently some people favor eyre over anyhow.

[LukeMathWalker]

In the community there is some shift in preferences and recently some people favor eyre over anyhow.

This claim needs a source.
eyre's download count is extremely stable: https://crates.io/crates/eyre
We're looking at 3M recent download for eyre vs 23M recent download for anyhow.

[LukeMathWalker]

As a "library-level" crate, we should use more specific error enums if possible.

That error variant must be opaque. The only alternative, here, is to define a custom opaque error in request-middleware. What's the benefit, beyond removing a dependency on anyhow?

[jennydaman]

This claim needs a source

https://blessed.rs/crates (scroll down to “Error Handling”)

What’s the benefit, beyond removing a dependency

Yeah, that’s all. This issue is just to be pedantic

[LukeMathWalker]

This claim needs a source

https://blessed.rs/crates (scroll down to “Error Handling”)

That's someone opinion—they're entitled to it, but blessed.rs has no official sanctioning whatsoever.
Even the "application Vs library" split is quite debatable.

[conradludgate]

The current middleware design cannot support a non type-erased error system. Some crates will use Box<dyn Error + Send + 'static> for this, but that often plays poorly with anyhow on both ends.

A tower-like service architecture is necessary to support nested error types, but reqwest-middleware has explicitly made the choice to not use that design. Perhaps we could reconsider in future.