Failure Crate Maintenance

#1

Due to an accident of history, I'm the only person who merges changes to failure and performs releases these days and I'm not very good at it. I also think that moving failure to use the the recently revised Error trait instead of Fail isn't worth it because of the work needed to be done by downstream consumers. In my view, downstream consumers are better off updating their error-handling code to newer and more actively maintained crates like thiserror, anyhow, eyre, or snafu instead of updating to failure 0.2.

Despite all that failure has done for the ecosystem, I've convinced myself that failure should be marked as deprecated and direct users to alternatives. Does anyone disagree?

34 Likes
#2

I agree. failure showed us what good error handling should look like, and now with the necessary changes merged into the standard Error trait, several new error-handling libraries arose that provide all the benefits of failure without the non-standard Fail trait.

I would suggest updating the README.md with an explanation of the history, and some examples of how to transition to other libraries. (For instance, how to transition to thiserror if you used custom error types and derive, or to anyhow or eyre if you used a catch-all error type.)

7 Likes
#3

I'll say as the original author of failure that I agree, and that I personally would recommend anyone who likes failure's API to migrate to anyhow.

36 Likes
#4

And thank you for not only developing failure, but contributing to the improvement of the error ecosystem overall.

13 Likes
#5

Thanks all, sounds good. Next steps for me are to:

  1. Create a PR with a deprecation notice, suggesting that people migrate to any of the libraries mentioned, with anyhow/thiserror taking priority because of @withoutboats's input above and original authorship of Failure. This will have a migration guide to anyhow/thiserror.
  2. Cut another minor release of failure, marking it deprecated on crates.io and docs.rs in a prominent location.
  3. (Optionally) Cut a PR to https://play.rust-lang.org/ to remove failure. Not sure what the policy for removing crates in the playground are, however.

@withoutboats: I'll say as the original author of failure that I agree, and that I personally would recommend anyone who likes failure's API to migrate to anyhow.

@josh: And thank you for not only developing failure , but contributing to the improvement of the error ecosystem overall.

+1 to that.

6 Likes
#6

The playground has the top 100(?) most downloaded crates. It is not manually curated.

#7

Adding

maintenance = { status = "deprecated" }

in Cargo.toml should help.

I wonder if the playground maintainers would be willing to take status = "deprecated" into account when constructing the list?

2 Likes
#8

It will still be on the playground if any of the other top 100 still depend on it.

I think the playground is not worth worrying about -- just let it fall out naturally as its usage declines.

3 Likes
#9

Perhaps have some sort of warning when useing the crate directly? It would be clear that it's deprecated while still allowing necessary usage (a la transitive dependencies).

#10

cargo audit has a way to warn about unmaintained crates (I am not sure if status = "deprecated" is sufficient to trigger that warning though).

#11

I wrote a blog post about this: https://boats.gitlab.io/blog/post/failure-to-fehler/

5 Likes
#12

Great post!

Since I don't see another place for reporting typos, there's an unfinished sentence in the middle: "but based on the std Error trait instead of on." [sic]

#13

I wasn't clear — I was referring to on the playground.

#15

Alright, I've deprecated failure. Thanks again all.

#16

Unfortunately cargo audit doesn't consume this information directly yet (although it could rather easily, and probably should).

If it's officially deprecated and there's a desire to do so, we can add an unmaintained crate warning for it, but failure is so pervasive it might be a bit noisy. Perhaps we could wait a bit for people to naturally transition and then file it.

2 Likes
#17

That seems reasonable to me. Let's wait for things to settle down a bit and then mark it as unmaintained in cargo audit.

#18

Glad to see the ecosystem moving forward.

That said, for the time being I plan to stick with failure, because failure::Error supports backtraces on the stable compiler, and anyhow::Error doesn't.

Might it make sense to wait for "feature parity" first?

(Is there another error library with backtraces on stable that I missed?)

#19

Cool, opened a tracking ticket for this, and tentatively suggested August 2020 (3 months from now) for filing an issue:

#20

You're welcome to stick with Failure, but I don't intend to publish any updates to failure in the future.

Snafu has backtraces. @yaahc's eyre and tracing-focused jane-eyre are interesting, more experimental alternatives. I believe jane-eyre builds on tracing-error.

(Full disclosure: I'm decently involved with tracing.)

4 Likes
#21

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.