Add logging compatibility layer

[felixfontein]

I've looked a bit into replacing twiggy with the standard logging library in antsibull-docs. While this is rather easy to implement (using infos from https://stackoverflow.com/a/75715402 to allow using {} formatting instead of % formatting in log messages), it would be quite a breaking change since suddenly the log output goes somewhere else and looks differently - and we'd need to parse the twiggy config from the app context to avoid some of the breaking changes.

That's quite some work, and work I don't really want to do, so I tried another approach: provide some logging warpper in antsibull-core that seamlessly replaces twiggy's logger - and for now simply uses it -, so that (in a later edition) the user can change the configuration to use the standard logging interface instead of twiggy, without any changes to the antsibull-core users (antsibull-build and antsibull-docs). Then for antsibull-core 4.0.0, we can remove twiggy support and force-migrate everyone to the "new" standard logging.

Ref: #39

[felixfontein]

The necessary changes to antsibull-build and antsibull-docs can be found in ansible-community/antsibull-build#666 and ansible-community/antsibull-docs#414.

[gotmax23]

I've been really busy, but I'll get to this as soon as I can

[gotmax23]

Sorry for the delay... I will take a closer look at the diff but the overall approach seems reasonable. A couple of comments:

1. We might want to switch to https://github.com/hynek/structlog instead of stdlib logging. It supports structured logging features similar to twiggy's fields() support so we wouldn't have to add extra code code for that part.
2. Instead of trying to add support for {} formatting which seems kind of hacky in stdlib logging and may not be possible in structlog, I think we should just switch to printf-style formatting. We could enable percent-style formatting in twiggy (https://twiggy.readthedocs.io/en/stable/reference_guide.html#alternate-styles) and do it now or do it later. I searched through antsibull-docs and antsibull-build for flog.*[^f]".*\{ and found a relatively small amount of log invocations that would need to be modified to use percent formatting.

[gotmax23]

notice() seems unique to twiggy; I guess we can just have this method call info() with the same arguments when/if we migrate.

[felixfontein]

• We might want to switch to https://github.com/hynek/structlog instead of stdlib logging. It supports structured logging features similar to twiggy's fields() support so we wouldn't have to add extra code code for that part.

That sounds interesting. Unfortunately it only supports printf-style formatting.

• Instead of trying to add support for {} formatting which seems kind of hacky in stdlib logging

It doesn't seem to be that hacky, by using own log messages it should work fine. This also allows to do structured logging, and write log handlers that handle the structured data.

and may not be possible in structlog, I think we should just switch to printf-style formatting. We could enable percent-style formatting in twiggy (https://twiggy.readthedocs.io/en/stable/reference_guide.html#alternate-styles) and do it now or do it later. I searched through antsibull-docs and antsibull-build for flog.*[^f]".*\{ and found a relatively small amount of log invocations that would need to be modified to use percent formatting.

That's something I really want to avoid. Originally antsibull was using printf-style formatting for logging IIRC, and I was very happy that it was possible to get rid of it. I really don't want to go back to it.

[felixfontein]

@gotmax23 how can we move forward with this?

[gotmax23]

I don't have a huge issue with printf-style formatting, and I remember reading that it's more performant than .format(). But it sounds like you have a plan here (although it's hard to envision what this would look like without having the logging-based implementation of the Logger class as part of the same PR), and I'd like to move forward with getting rid of twiggy also, so I think let's do it.

[gotmax23]

I didn't look at all the docstring changes in detail, but the code looks okay to me.