Custom options for color_backtrace about color-eyre

[winstonewert]

I think re-exporting color-backtrace's configuration with an install method that handles both makes a lot of sense.

[winstonewert]

Sorry, I wrote that wrong...

What I meant was that color-eyre could implement its own panic handler instead of calling the color-backtrace install method. Then it doesn't matter that color-backtrace's install takes the BacktracePrinter by value since you wouldn't call it.

(You figured out how to solve the cloning issues as I was typing it up, so its certainly not as compelling a solution now)

[yaahc]

This sounds like a great idea, thank you! I'm thinking the best way to do this would be to add a static variable for storing custom filters and some functions for manipulating this global filter set which you can call at the beginning of main to setup your custom filters. Would that work for you? It would add a global RWLock that has to be read from every time format a Report but given the fact that error reporting probably isnt in the critical path I'm guessing this is a good tradeoff.

[winstonewert]

Well, there are other options on color_backtrace as well: color scheme, message, etc. It seems to me that a user might want to configure those as well. So maybe not an api that only allows setting frame filters? (I don't need more then that... but maybe somebody does).

I think the ideal API would be to get a function added to color_backtrace that returns the currently installed BacktracePrinter. Then whatever settings are put in to the color_backtrace install automatically apply to eyre-color.

Perhaps a slightly less ideal api would be a static variable in eyre-color that stores the current backtrace printer with some sort of install function to set it. Then I'd just install my backtrace printer into both color_backtrace and eyre-color.

[yaahc]

Aah yea fair, one thing I'm worried about is that by making ourself dependent upon the API of color-backtrace we'd have to make a breaking change every time they do. That said, it may be worth it to couple them together, I doubt any breaking changes made in color-backtrace would be disruptive, if it even happens any time soon.

Maybe we should just reexport the configuration and install part of color-backtrace's API such that calling install with a color_eyre::BacktracePrinter sets up both the panic printer and the Report backtrace printer. This wouldn't even require adding a method to access the global BacktracePrinter in color-backtrace.

This will also require some updates to color-spantrace so that it uses the same color pallet as color-backtrace when a custom printer is installed.

cc @athre0z

[yaahc]

It looks like BacktracePrinter isn't Clone, so we will have to fix that before we can reuse a BacktracePrinter in two places.

Edit: oof, it can't be made clone without making a breaking change to the callback type :((((((

Edit 2: the callback is an Fn trait object so I cannot add a Clone bound to it 🙃

Edit 3: Arc<T> impls From<Box<T>>, victory!

[winstonewert]

Alternatively:

color-eyre will have to maintain a static variable holding the BacktracePrinter.

Instead of calling color_eyre's install, it should install its own panic handler that fetches the BacktracePrinter from from the static variable. Then there is no need to clone the BacktracePrinter.

[yaahc]

@winstonewert color-backtrace's install method takes the BacktracePrinter by value so you cannot install it into a static defined in color-eyre and the global panic printer at the same time. If I'm understanding you right that you mean to call install on color-backtrace and color-eyre separately that would work but I don't think it's a great API.

I think I'd rather wait until the PR to make BacktracePrinter Clone merges. areth0z is normally extremely responsive so I bet they will merge it as soon as they wake up. That way I can provide the single configure + install interface from color-eyre.

[winstonewert]

But to throw another wrench in things, it occurs to me that you might not want exactly the same settings between panicing and errors. In particular, I suspect that the desired panic message is different then the desired error message for many people.

[yaahc]

hmm, yea. I wonder if calling color_backtrace::install after you've already installed a panic printer works fine. Hopefully yes, that at least would let people separately call the second install method to get the different setup.

I have another wrench as well, BacktracePrinter doesn't expose the colorscheme as part of its API, only a setter method, so I cannot look inside of a BacktracePrinter to see what colors it has configured so that the SpanTrace / error messages / help text highlighting is updated to match. I'll tenatively open a PR to add an accessor method to retrieve a reference to the internal ColorScheme I guess...

[yaahc]

I think I'm going to timebox this, I'm going to provide an initial API for setting the backtrace printer just for color-eyre. I'm not gonna bother with the also set color-backtrace's printer or with the be consistent with coloring changes as part of this issue, that way at least you can promptly get your custom frame filtering. It should be easy enough to add the extra features later when people end up needing them without making breaking changes.

[yaahc]

@winstonewert I've pushed an implementation of the change with #17, can you test it out and lmk if it works for you before I go ahead and merge it / make a new release.

[patch.crates-io]
color-eyre = { git = "https://github.com/yaahc/color-eyre.git", branch = "filters" }

[winstonewert]

Worked great.

[yaahc]

Alright, v0.3.2 should be good to go with the filter feature setup. Thanks again for the suggestion!

[winstonewert]

Thanks!