Rich logging

[MinchinWeb]

Further to #2869, this expands rich's usage by extending it to cover logging.

This has the side effect of somewhat simplifying the logging code we need "in house" as some of this is pushed to rich.

Current (v4.6.0) logging:

Logging with this PR:

Pull Request Checklist

• Ensured tests pass and (if applicable) updated functional test output
• Conformed to code style guidelines by running appropriate linting tools
• [ n/a ] Added tests for changed code
• [ n/a ] Updated documentation for changed code

Re formatting: On my side I'm showing quite a large number of files that would be reformatted by black and isort. I'm not going to make those changes here...

[avaris]

Shiny ✨ . I'll review once I have time to test this. By the way, does this help with #2896 ?

[MinchinWeb]

Ah yes, this would close #2896!

The "Generating..." spinner is still there (if you're sharpeyed, you might see it in the above screen cast); the trick was to use the same console.

[avaris]

Left some comments, but overall looks really nice. Thanks!

[MinchinWeb]

This also updates the formatting of the "Found Writer" debug message to match the Generators:

           DEBUG    Found generator: ArticlesGenerator (internal)                                        __init__.py:211
           DEBUG    Found generator: PagesGenerator (internal)                                           __init__.py:211
           DEBUG    Found generator: GPXGenerator (pelican.plugins.gpx_reader)                           __init__.py:211
           DEBUG    Found generator: StaticGenerator (internal)                                          __init__.py:211
...
           DEBUG    Found writer: XMLWriter (pelican.plugins.xml_writer.writer)                          __init__.py:228

[MinchinWeb]

I've also expanded the use the rich.console to the --print-settings CLI option, particularly when there is an error in your pelicanconf.py.

General errors (as run through the FatalLogger / LimitLogger) only display the error message but not the error class. I'm not sure how to "fix" this, but it was "broken" before I started...

[avaris]

General errors (as run through the FatalLogger / LimitLogger) only display the error message but not the error class. I'm not sure how to "fix" this, but it was "broken" before I started...

Which ones are those? If you mean logger.error(...) cases, then those are only logs, they are not necessarily associated with an exception, so no error class.

[MinchinWeb]

General errors (as run through the FatalLogger / LimitLogger) only display the error message but not the error class. I'm not sure how to "fix" this, but it was "broken" before I started...

Which ones are those? If you mean logger.error(...) cases, then those are only logs, they are not necessarily associated with an exception, so no error class.

Yes, it was logger.error() cases, although I can't remember exactly which ones at the moment.

In any case, I didn't change the behaviour, it just seemed off at times.

[justinmayer]

Unrelated note: Maybe we could add support for Better Exceptions, much like my friend Hynek just did for Structlog.

[avaris]

Somewhat related note: The only remaining non-rich output is the server.py (and a print in it's counterpart in listen function from __init__.py). To make the server use console, simply defining a log_message method in the handler and replace the original sys.stderr.write with console.print or console.log would be enough.

I was also thinking about making autoreload message a status/spinner as well but -lr (--listen --autoreload) makes things problematic. Even if you "share" console, server messages disrupt status and results in similar issue as #2896. I'm 99% certain that the culprit is multiprocessing and in fact the console instances are not really same, but solution will be tricky.

[justinmayer]

@avaris: Any chance you could take another look at this and update your review with any remaining items to be addressed, if any?

[justinmayer]

@avaris: What do you think we should do in terms of moving this forward?

[avaris]

Thanks

[avaris]

Sorry about that, I think this is good as is. We can always add further enhancements later.

[justinmayer]

@avaris: No need to be sorry! You raised some good points, which hopefully we can use as guidance for further improvements in the future.

@MinchinWeb: Many thanks for these enhancements! Very cool, indeed. 💯