-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[REQUEST] Improved uninstall for rich.traceback.install
and rich.pretty.install
#2461
Comments
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 |
I'd accept a PR for an |
Cool, thank you! Any tips on implementation? e.g. how would you store the pre- |
It needs to handle both cases:
|
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. #2455, #2408), and more generally, users have asked whether they can uninstall rich tracebacks. See also #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.The text was updated successfully, but these errors were encountered: