Polite reminder @yaahc

Thank you, I'm sorry for the long delay, I'll make sure to resolve this asap (probably after the new year).

I've been watching this thread as I recently ran into the same error message after introducing a seemingly unrelated change on a project and finally figured out what was going on. I'm documenting it here in case it can be useful to others.

When the auto-install feature is enabled (which it is by default), if an error handler is needed but one isn't configured yet, eyre will install a default one: https://github.com/yaahc/eyre/blob/c32a8d0b6799ef4c862df1034202f9d6e5a5f400/src/lib.rs#L600-L603

What happened in my case was that I introduced some code that triggered and logged an eyre::Report before the code that setup the error handler, which meant that by the time it was executed the default handler was already in place. This led to a lot of confusion on my part as I wasn't aware of the default handler behaviour and assumed I was somehow trying to set up a handler twice.

This is quite similar to your description @xphoniex, as in my case the new code I introduced was actually checking for the presence of a file that exists on some systems but not others.

Hope this helps.

I was able to solve this exact issue by ensuring that git and libusb are installed on the new machine where the compiled binaries are moved to. Hopefully this helps for your issue.

Sorry, a bit confusing, is this a typo, or does commit 615d16c actually resolve this issue @dbanty ?

Edit: I think that commit refers to this issue, might wanna re-open this @ten3roberts

Hmm, looks like pulling color-eyre into the workspace also pulled in the commit history, which means commits that referenced closing issues for color-eyre now retroactively closed issues for eyre 😱. What a fun problem 😅

Thank you for putting this to my attention.

Not only is it closing issues, but closing unrelated issues just because they have the same issue number, grr.

I'll go through any other closed issues and see if there are any more to reopen (and fix 😝 )

As stated in the issue, it is the auto install being a footgun, which imho is an anti feature.

Tracing does not do anything by default as this easily leads to unexpected behavior.

We've run into a similar issue with the compile probes, and want to give all this a stir up and remove the probes and instead opting for cargo cfg flags to enable nightly behavior as they are prone to silently breaking or misleading behavior.