Remove thiserror crate

[Bzomak]

Manually implement std::error::Error and std::fmt::Display for the Error enum, rather than using the derived implementation from thiserror.
This should provide a compile time benefit, especially on slow machines.

[harryfei]

Sorry, so late to response on this. How much time does thiserror's compilation cost in your case?
You know, maintaining the manually implemented code is somewhat annoying. So we use the thiserror to avoid that.

[Bzomak]

Sorry, so late to response on this. How much time does thiserror's compilation cost in your case?

No worries! I've run some builds to give you some data!

With thiserror:

cargo clean; cargo build
4.98s
4.85s
4.94s
4.95s
4.98s
=> Average: 4.94s

cargo clean; cargo build --release
10.70s
9.51s
9.80s
9.63s
9.80s
=> Average: 9.89s

Without thiserror

cargo clean; cargo build
1.49s
1.45s
1.49s
1.48s
1.49s
=> Average: 1.48s

cargo clean; cargo build --release
1.48s
1.41s
1.43s
1.42s
1.41s
=> Average: 1.43s

I had been getting results of about 6s, 12s, 1.5s and 2s before, but I couldn't reproduce those numbers - I assume that there were more background processes running at the time, but even with these latest numbers you can see a pretty decent increase.

You know, maintaining the manually implemented code is somewhat annoying. So we use the thiserror to avoid that.

Sure, completely agree with the principle. After all, this is why I'm using this crate to check if a program is installed, rather than doing my own thing and likely messing up all the edge cases. And if you'd used thiserror in a lot of places with multiple errors, and/or used some more of thiserror's various attributes, I may not have bothered with this pr. Likewise if this crate was under heavy development. But it seems pretty stable, and the "manually implemented code" in this case boils down to essentially a single trivial match statement, which I wouldn't have thought would cause much of a burden!

[extrawurst]

unless you do something very bare bone chances are good that you have thiserror in your dependency graph anyway. I don't mind which using it. I use it myself in asyncgit

[Xaeroxe]

Hello, new maintainer here. I'm not sure we're getting enough benefit from thiserror to justify its inclusion, nor am I convinced thiserror is required for anything non-trivial in Rust as this is the first I've heard of it in 6+ years of writing rust. I'm going to merge this PR.

Normally I'm in favor of reducing workload with small dependencies, but in this instance the rust compiler will tell you when you're missing a new branch in the match statement, so the actual maintenance burden is about the same.