Maintainership of failure

[withoutboats]

Its obvious that I have too many things on my plate, and long term maintainership of failure is going to be one that gets dropped off. I'd like to try to push it over to a 1.0 release and then largely pass on authority over this crate to a team of interested individuals. In the long run I am also in favor of pulling parts of the API here into std, probably starting with a standardized backtrace API.

If anyone is interested in being involved in maintaining failure, please post your thoughts here. :)

cc people who have expressed interest in maintaining failure in the past: @aturon @mitsuhiko @kamalmarhubi

[mitsuhiko]

I'm very interested in this. Feel free to drop me a mail and we can have a chat.

[kamalmarhubi]

I'm also quite interested in doing what I can to get this to 1.0 and beyond.

[otavio]

I am too new to Rust to take a maintainership role but I am willing to help to test and even reviewing stuff.

[aturon]

Great to see this picking back up! I don't have bandwidth to be very actively involved, but I would like to try to do a "brain dump" of the notes I had taken when I was more involved, to pass along to y'all. I'll try to do that soon.

[withoutboats]

Thanks for writing in everyone! 🎉 I think we should start by trying to get a stable release out & setting a roadmap for feature priority beyond 1.0.

I've started labeling issues that need a decision before 1.0 (because it would be a breaking change to change them). The other big thing that needs to be done is to review the code to make sure its all correct - for example, I was told the throw! macro is subtly different from the behavior of ?, so that needs to be fixed.

[withoutboats]

Oh I also want to do a "crater run" for 1.0.

The way the 1.0 release is planned, the 0.1 version should be "compatible" with the 1.0 version, in that none of the breaking changes change the public API someone could re-export from failure. They change code generation, but not the API of Error and Fail. This uses the dtolnay semver trick.

The way this works, the next 0.1.X release will have a dependency on the 1.0.0 release. I want to actually build all the crates on crates.io against the new 0.1.X version to confirm it is indeed not a breaking change for anyone.

[BurntSushi]

I'm interested as well. I am also stretched quite thin myself, but I care a lot about error handling and so I would like to help out where I can.

[kamalmarhubi]

@aturon that brain dump, however raw, would be super useful!

@withoutboats are there any areas you'd want new / prospective maintainers to start looking at in the very near term?

Also when thinking about the API, I hope we can get your input on things occasionally. You're both really thoughtful API designers, and ideally failure keeps being thoughtful even if you're less directly involved. :-)

[aturon]

@kamalmarhubi Oh, I'm very happy to be consulted as things come up, just can't lead the charge.

So, I have a few sets of notes. First, there are two very rough notes written by other folks who were struggling with the crate:

• Challenges learning failure
• failure issues
  • Note that this one, in particular, contains incorrect information based on misunderstanding; I have some comments on the side where this happens. But that's useful feedback in and of itself!

Then, there's a set of notes I wrote trying to lay out my own view on how the crate should be used and what direction it should go in:

• How to failure

A central aspect in all of this is that the core mechanisms are pretty simple/uncontroversial, and most of the issues are around docs/advice/patterns.

Please feel free to ask any clarifying questions here. This stuff is very out of cache for me right now, but if you poke me I should be able to dig the thinking back out.

[mitsuhiko]

I'm still very interested in maintaining this project but I would like to vote on not releasing failure without a lot of further consideration. There are a few API warts that I think are very resolvable but were not properly discussed yet. If there is interest I would like to write down some notes on problems we ran into and some proposals we have for solving them.

[aturon]

@mitsuhiko Agreed!

Personally, I would love to see some equivalent of an RFC if/when maintainers feel they have a 1.0-ready design, to build community consensus and pave the way toward eventual inclusion in std.

[withoutboats]

@mitsuhiko I completely agree that the APIs need careful review before any 1.0 is released. Things like the unnecessary where Self: Sized bound you caught today are good examples.

Where @aturon and I have had some disagreement in the past is that I think a significant or fundamental revision would be better done as a new crate than having failure 1.0 be different in a really big way from failure 0.1. I also strongly value having types between 1.0 and 0.1 be interchangeable.

[BurntSushi]

Where @aturon and I have had some disagreement in the past is that I think a significant or fundamental revision would be better done as a new crate than having failure 1.0 be different in a really big way from failure 0.1. I also strongly value having types between 1.0 and 0.1 be interchangeable.

Interesting. I didn't consider this, but I definitely have grown some very loose opinions about doing things somewhat differently than what failure is doing. But since I haven't experimented with it at all, I don't know how well those opinions would work out. Mostly the thing stopping me from pushing forward is the desire to coalesce on one answer (failure), and, of course, time. But maybe I'll try to slap something together.

[aturon]

A related issue to this discussion: whether there are perhaps some separable pieces at play here. I think we all agree that the Error trait in std is broken (e.g., because it failed to impose the 'static bound needed to support downcasting); if we can at least get agreement on a replacement core trait, that'd be a big step forward.

[mitsuhiko]

I’m quite worries that stabilizing failure too early will get us into the same situation as we were with std::error. The more I use the crate the more I both appreciate as well as notice peculiarities in it that are confusing. And this confusion I think is not necessarily an intentional decision but a limitation of the language.

For instance that Error is not a Fail causes all kinds of weird behaviors. Moreover other frameworks such as actix have started extending Fail and now begin to show limitations in the current setup cause by language limitations. For instance if trait X: Fail is something that should be supported (which i think it should) then we have a lot of methods on Fail which cannot be called without having another base trait that lets us convert a trait subtype into the fail base trait.

There are many more such cases where it’s unclear if stabilizing the trait atm is a good idea.

[BurntSushi]

@aturon Yeah, agreed. I don't think I have many qualms with the Fail trait itself. Most of my thoughts revolve around how Display works by default, the cause chains and the Context. My thoughts are super unformed though, which means it's possible that failure could fix most of these things within its current framework. Apologies for being so evasive!

[kamalmarhubi]

if we can at least get agreement on a replacement core trait, that'd be a big step forward

If this is an explicit goal of Fail, we should start drawing out the constraints. I know at least I'm unclear on what these are after reading discussion above + docs linked. Here are some potential ones I've gleaned:

• a reasonably ergonomic interop with Error
• performance, eg by keeping size down
• compatibility with failure 0.1
• obviousness of how it should be used
• nostd support
• extensibility: trait X: Fail

There are certainly more, so please add or clarify. Then we can figure out which are non-negotiable, and that will make the space smaller and (hopefully!) easier to explore.

I'm most interested in the obviousness-of-use one. There's clearly a lot of confusion over which of the patterns you're meant to use, which I share. If we can't whittle it down to just one pattern, we should at least aim to have it summarised in a flowchart that answers 90+% of use cases quickly.

[mitsuhiko]

So here are my personal nitpicks I want to get figured out:

• relationship between Error and Fail. In particular: why is Error not Fail itself? Why is it AsRef<Fail> but not Deref<Fail>?
• Why is err_msg described as "Constructs a Fail type from a string" if it actually creates an Error which is not Fail?
• Do we need to carry the compat() methods on the Fail and Error, could we find a way to move them to a temporary extension trait for now?
• Ergonomics around error kind patterns with additionally shared extra contextual information (guidance on handling the display of io::Error with file paths #189 (comment))
• Unify map_err and context in an extension trait?
• Are we sure context is the right API?
• Resolution for Duplicate implementations with same name #211
• How to deal with X: Fail extensions not being able to call fail methods.

[Dylan-DPC-zz]

Interested in maintaining this as well 👍

[kngwyu]

I think it's great if display_derive also get new maintainers.

[lucab]

Can we maybe start by having the current failure-1.x pushed out as a 0.2.0, and iterate from there towards a 1.0? There are already useful changes in there piled up since last release, and by reading the comments here it looks like there are quite a few design/discussion points still before 1.0.

[mitsuhiko]

@lucab i was playing with this but I have to figure out how to make a crate run first.

[aturon]

I wonder if one of the volunteer maintainers could step up as a "lead" maintainer, at least at the outset to help things get going? I worry that right now there's a diffusion of responsibility.

[Dylan-DPC-zz]

@aturon sure :) i'm in for that

[mitsuhiko]

I don't know who can decide on who that person should be, but yeah. I'm up for doing that. I care too much about this crate for having it stay in this state it is right now.

[mitsuhiko]

Also as of why I did not actually try to PR anything: right now the way master is shaped makes it a both a bad release target for a point release as well it being unclear if we can move forward this way. It attempts to stay type compatible between 0.1 and 1.0 and the things I want to change can no longer satisfy that.

[otavio]

@mitsuhiko I tend to agree. I think we should branch 0.1.x out and do bug fixes there and clean master to have 1.0.x material. Also, a 0.9.x release would be welcome to prove few things of 1.0 work.

[Dylan-DPC-zz]

Yeah i agree. Jumping directly from 0.1 to. 1.0 might not be the right thing to do at the moment.

[mitsuhiko]

From what I can tell there are enough people willing to work on this crate. I think it needs an external person like @aturon to appoint :)

[mitsuhiko]

@aturon are there any updates on this?

[jonhoo]

A somewhat related question here is what we do with failure 0.1 in the meantime. It currently has very outdated dependencies, and releasing a minor version bump that at least ups the dependencies while we're working out failure 1.0 would be warmly welcome 👍

[mitsuhiko]

I would love to do that. I also have a PR that I want to merge which makes the compat type more useful for downcasting (#213).

[jonhoo]

@aturon @withoutboats I think we're currently blocked on you here. The consensus seemed to be to hand over the commit part to @mitsuhiko?

[aturon]

Hi y'all! Apologies for the delay. @mitsuhiko has an invite with admin rights to the repo, and is the designated lead for moving things forward here.

The plan, as I understand it, is that @withoutboats is going to write an RFC soon for fixing the Error trait in std, with the intent that this trait provides the core notion of what an error in Rust is, and other libraries (like error-chain and failure) are primarily ways of crafting/working with errors.

[jonhoo]

@mitsuhiko I posted a PR that updates the dependencies for failure 0.1 in #228 :)

[mitsuhiko]

Thanks @aturon. Going to take good care. If I want to do a release, who do I poke since I don't have access to crates.io?

[aturon]

I think @withoutboats will have to grant that access (or do the publication).

[withoutboats]

I've written an RFC about fixing the Error trait in std. Feedback from the people interested in failure would be very greatly appreciated! rust-lang/rfcs#2504

[mitsuhiko]

I am closing this now as this is solved now (other than crates.io) access.

[withoutboats]

Working on getting crates.io access set up using a github team but lacking some of the necessary privileges. Also, I'd like to be looped in on any plans for breaking changes to discuss the ecosystem impact.

[Dylan-DPC-zz]

@withoutboats i think it is better if we create a separate organisation the same way we did for UUID & Bitflags. It become easier to set up a team if required.

[mitsuhiko]

@withoutboats you forgot failure_derive: https://crates.io/crates/failure_derive

[kngwyu]

How about display_derive ?

[mitsuhiko]

@kngwyu for now I'm going to pretend it does not exist. Moving over to it would be a breaking change to failure I want to avoid for now.

[kngwyu]

@mitsuhiko
I see, thanks.
But since display-derive is already on crates.io, I hope it'll be maintained in the long run 🙂

[little-dude]

Hi,

What's the current state of maintainership ? It seems like there was a spike of activity in July, but since then many PRs/issues haven't been looked at.

I don't mean to rant, I know this is open source and that people work on it on their free time and I'm very grateful for that. It's just that I started converting code to failure recently, and I'm wondering if the crate is going to be actively developed, and just be in minimal maintenance mode in the future.

[mitsuhiko]

@little-dude this is largely my fault. The reason for the lack of activity is mostly that I do not know what to do with it right now given that the entire state of error handling in Rust is in flux again.

[otavio]

@little-dude this is largely my fault. The reason for the lack of activity is mostly that I do not know what to do with it right now given that the entire state of error handling in Rust is in flux again.

I think this should instead motivate the faster experimentation and releases as it allows for trying the options without all the commitment that comes of having things on std.

In my point of view, 0.1.x should be in maintenance mode and a 0.2.x cycle should begin allowing for breaking changes and incorporating improvements at a fast pace. If something is seen as bad, 0.3.x can be made to fix it ...

[mitsuhiko]

@otavio it should, but it's not because Failure is incompatible with what's happening in std lately so it seems like we are most likely going to have to build a new major version of failure to re-enter that ecosystem.

[mitsuhiko]

I am kinda operating under the mode of looking at when the new std::error thing lands and then what will still remain of failure and how.

[otavio]

I understand but Failure could be anticipating few of those additions and also put them under a wider set of test cases. When things lands on std::error, a new major release can be made to take it into account ... but I think there is a number of good PR waiting for review / merge and we risk of having people doing forks or hacks and fragmenting the ecosystem instead of use this energy to converge more people in getting the error handling to the next level.

[little-dude]

The reason for the lack of activity is mostly that I do not know what to do with it right now given that the entire state of error handling in Rust is in flux again.

I am kinda operating under the mode of looking at when the new std::error thing lands and then what will still remain of failure and how.

That makes sense. I was not aware of all these changes and how they impacted failure. Is it only rust-lang/rfcs#2504, or are there other changes in the pipe that will affect failure? I've tried reading through the RFC and the comments but I'll need more time to digest it.

Anyway, the takeaway is that failure will continue to be developed, and that things are a bit slow right now dues to upcoming changes in the standard library. It might be worth adding a note in the README about that.

Thanks a lot for your efforts on this @mitsuhiko !

[aturon]

FYI: the Error trait has received some of the relevant updates, but still needs backtraces. @alexcrichton left a mentoring comment if someone wants to pick this up; it doesn't seem too tricky.