Install rich.traceback globally for a venv

[TroyWilliams3687]

I recently discovered the Rich library - fantastic stuff. I do a lot of simple CLI work and am investigating how I can use it with Click effectively.

In the meantime, I have an immediate use case for Rich, the traceback module. It is wonderful. I currently use pretty errors to nicely format all unhandled exceptions by installing it globally in my virtual environment. I have a set of makefiles that handles this automatically.

Looking at what pretty errors does, it basically installs to ./.venv/lib/python3.9/site-packages/sitecustomize.py and inserts code to run pretty errors. Testing this out, it seems the following code in sitecustomize.py works well

from rich.traceback import install
install(show_locals=True)

That seems to apply the traceback to all unhandled exceptions! I thought I would share in case anyone else is looking for this particular use case. I have a lot of repos for experimental and prototype code. This use case works well for me.

Are there any problems that could occur by doing this?

I was wondering how much effort it would be to properly allow Rich to install itself that way? There might be more use cases that it could deal with in this fashion. For now, I am quite happy to modify my makefiles to do this.

Thanks,
Troy

[willmcgugan]

That’s a fine solution. As far as I can tell pretty errors is doing much the same thing.

Not sure if I would want to do the automatic install to Rich. That seems to be beyond the remit of a library. Documenting the process in the docs may be a decent compromise.

[TroyWilliams3687]

Excellent! Thank you for your feedback Will. I agree with, I don't think a library should be installing itself. I think putting a note in the documentation would work fine as a special use case. If you let me know how I can help, I would be happy to draft something up?

[willmcgugan]

I'd accept a PR for the docs. If you check the docs directory you could edit the RST file for this page.

[TroyWilliams3687]

Alright, let me give it a shot.

[gennaro-tedesco]

I have a similar doubt and was wondering if the opinion on the matter has changed since, namely regarding the part

I was wondering how much effort it would be to properly allow Rich to install itself that way?

Not sure if I would want to do the automatic install to Rich. That seems to be beyond the remit of a library.

Is manually amending the file ./.venv/lib/python3.9/site-packages/sitecustomize.py the best practice? This can be done ad hoc locally by every user, however for applications that are deployed on instances or run in production often people do not have access to such files (and I would argue that one shouldn't manually change virtual environment properties themselves either); moreover different virtual environment frameworks may handle this differently.

Wouldn't the idea of a "rich configuration file" be a good solution for such matters, namely something along the lines of a project-specific rich.toml

[traceback]
global = true
exclude = 'test/test_*.py'

[print_json]
global = true

that takes on specifics for all the methods that rich can override?