Re-design Logger hierarchy

[lihaoyi]

The Logger interface is a bit of a mess, doing a bunch of different things some Mill-internal and some user-facing. #3577 extends it a bit but makes it even more messy.

Probably we should have more narrow specialized Logger interfaces for different parts of the codebase, e.g. the logger inside a Task would have a ticker, whereas the logger outside would not, and a top-level logger would have more power to do things like configuring the prompt that task-specific loggers would not have. close() probably needs to be re-thought since the lifecycle of the various loggers is all different, with some short-lived and some long-live

The whole color scheme and debug/info/warning/error conventions also need to be redone. Currently infoColor is blue and normally used for "less important" things, but then logger.info uses it for normal-important things. And how should a user decide between info and just println? When should subclasses of Logger put logic into overriding info vs injecting logic into stdout/stderr streams?

Arguably, all the concrete FooLogger classes should be private[mill], since there's no reason that a Mill user would need to instantiate their own PrintLogger or whatever.

This would break bincompat and would have to go into 0.13.0

[lihaoyi]

At time of writing this is the current logging hierarchy that is typically available inside any Mill task:

MultiLogger(
    PrefixLogger(
        PrefixLogger(
            PromptLogger("foo.test"),
            "",
            ""
        ),
        "[106] ",
        ""
    ),
    FileLogger(/Users/lihaoyi/Github/mill/example/scalalib/testing/4-test-sharding/out/foo/test/test.log)
)

[lihaoyi]

With #4653 and #4658, most of the superficial cleanups have been done. The next big questions are around the architecture of the logging API

What do we want to do with debug, info, and error?

1. Do we want to immediately fold them into stderr? That would simplify things considerably, but lose flexibility: e.g. we would no longer be able to separate these logs into separate files if we so desired

2. Do we want to keep them separate? That is what we do now, and it adds considerable complexity, which we currently don't really make use of or benefit from

Different logging libraries have varying degrees of sophistication in how they handle log levels. Currently Mill just stuffs them all into stderr with different colors, and debug is silenced unless the --debug flag is passed. If that's all we want to do, we can simplify the code considerably by hardcoding that assumption in the code. If we want to do more than that, we should figure out what exactly we want to do and design the API appropriately. Currently we have the worst of both worlds with all the complexity but no benefits

How should --ticker false interact with --disable-prompt?

Currently the various combinations of --ticker {true,false} and --disable-prompt` result in 5 different configurations for the CLI.

1. --ticker false disables the multi-line prompt with no replacement, and removes some (but not all) of the line-prefixes
2. --disable-prompt swaps from the new multi-line prompt introduced in 0.11.x to the older single-line ticker.
3. If neither flag is passed, the prompt runs in "non-interactive" mode where instead of using terminal control codes to live update your terminal, it instead prints out a snapshot periodically to stdout (default every 60s)

Currently, only three scenarios are actively used and tested

1. Currently basically all manual testing is done with the default setup, while all integration and example testing is done with --disable-ticker.
2. The non-interactive mode is used in CI
3. --disable-prompt doesn't seem to be exercised anywhere at all, though manually testing it it seems to still work (kind of, the ticker sometimes disappears?)

Do we need all 5 options, or would fewer options be sufficient?

[lihaoyi]

Going to call this done. The design can always be better, and we can continue improving it, but I think this meets the minimum threshold of quality and tidyness for now

[lolgab]

I would love to be able to set a global level as I can do with sbt.
Also, we are missing warn, which many tools support (the scala compiler as well).

[lefou]

I would love to be able to set a global level as I can do with sbt.

I'm not a sbt user. Can you explain, how that would look like for Mill?

Also, we are missing warn, which many tools support (the scala compiler as well).

Yeah, I'd love to have that, too.

[lihaoyi]

@lolgab @lefou you guys may have to drive the improvements here, I'm not really a logging system connoisseur and don't really have opinions what makes a logging system good or not, but if you guys do then 0.13.0 is our chance to improve things

[lolgab]

@lihaoyi I can start by opening a PR to add def warn to Logger to be able to print yellow warnings.