Open antonymilne opened 1 year ago
Rather than uninstall it, could you provide an env var to not install it in the first place?
Thanks for the very rapid response! That is indeed our currently proposed solution (probably wouldn't a an environment variable due to how kedro works, but some sort of user-specified option that would skip the call to the rich install
s). It's not ideal from our perspective for various reasons (e.g. it's not clear where this would live and how it would operate differently for both IPython and non-IPython workflows). Also, given that rich.traceback.install
already sort of has a mechanism built-in to undo its replacement of sys.excepthook
, I thought that a fully functioning uninstall
feature would belong on rich also. So I just thought I'd gauge appetite for doing this here and whether it's something you'd accept a PR for or not.
I'd accept a PR for an uninstall
function.
Cool, thank you! Any tips on implementation? e.g. how would you store the pre-install
IPython settings. A global variable? Make a class to contain the state and then install
/uninstall
functions that access that class?
It needs to handle both cases:
sys.excepthook
and I haven't figured out how to restore it.install()
return the original hook, you can just override it with sys.exceptionhook = old_hook
We are very excited to have recently adopted rich on the Kedro framework. In short, our setup is:
Some people have reported various issues (e.g. https://github.com/Textualize/rich/issues/2455, https://github.com/Textualize/rich/issues/2408), and more generally, users have asked whether they can uninstall rich tracebacks. See also https://github.com/Textualize/rich/discussions/1947.
Now there are a few problems:
rich.traceback.install
in order to restore itrich.traceback.install
modifies various things likeip._showtraceback
. However, the function only returnssys.excepthook
. Hence, even if a user were able to capture the call asold_excephook = rich.traceback.install()
, it would not provide sufficient information to fully undo the effects ofrich.traceback.install()
rich.pretty.install
has caused fewer problems for users so is less important to try to uninstall, but it does not return anything at all and hence, even if you had access to the code that calledrich.pretty.install
, there's no way to reliably reverse the callSuggested solutions
A new
rich.traceback.uninstall
functionality that fully reverses the effect ofrich.traceback.install
. This would not require the user to be able to access the call toinstall
in the first place and would also work on IPython. Similarly forrich.pretty.uninstall
(but less important to us).Current workarounds
This is not quite right because it doesn't restore things to how they were before the rich
install
s; it just resets them to the Python/IPython defaults. Hence on platforms such as Databricks, where it's difficult to figure out what the correct in-built Databricks customisations to exception handling etc., the above uninstalls aren't correct because they don't restore the settings to their databricks pre-rich-install state.