Julia: Option to disable the location info of a logging message

[KristofferC]

I would argue this is quite rarely wanted. Perhaps it should even be off by default?

Anyway, an option to disable it is probably needed. @c42f

[c42f]

For sure, options here are good, though not in SimpleLogger - I think a stdlib Logging.ConsoleLogger with the bells and whistles would be the place to add lots of functionality. In fact I'd like to remove even more functionality from Base.CoreLogging.SimpleLogger if possible, and leave it completely bare bones.

My current best try at something readable which also retains metadata is MicroLogging.InteractiveLogger which you can get by just doing using MicroLogging on the MicroLogging master branch. See also the first point in #25109.

The annoying thing about logging metadata is that you don't want to see it most of the time, but when you do want to see it, you really want to see it and you curse yourself for turning it off. Which leads me to think that the logs could be saved with full metadata to a log file, with the ability to replay them for more detail on the console if necessary. But I haven't implemented any of that yet.

Regarding a full logger configuration system - this is something I'm planning to ignore for now in lieu of getting other logging related cleanup done, but is an important part of a complete system.

[KristofferC]

So to prevent:

I should now not use the logging system at all? That's fine by me since I mostly just want to print a colored message.

[c42f]

Definitely use the logging system, @info is designed for what you're doing here, and if you can't use it, then this is a failing of the system and should be fixed.

If the default formatting is ugly, well we just need to fix it - which is my point that we should have a nicely formatted ConsoleLogger as the default, rather than SimpleLogger which is what you're currently seeing. The reason that you're seeing SimpleLogger rather than something prettier is that the deprecations to info()/warn() needed to go in before feature freeze.

By the way, I'm expecting to clarify in the documentation that log messages are expected to be markdown formatted, so if you want to provide formatting in the log messages that should be useful. For example, a summary of Pkg3 actions could be provided as a markdown table and ConsoleLogger should be expected to make that pretty.

[c42f]

To clarify, Logging.ConsoleLogger doesn't yet exist, but it should. It should be the default for the REPL, and it should format things in the most readable way possible.

[nalimilan]

The formatting looks fine to me, it's just that the line numbers are clearly irrelevant here, we're not debugging anything in this case.

But is it really what logging is designed for? To me, logging is more for messages which either indicate problems, or can be ignored and are just of interest when debugging. The messages we're talking about here are very different, they just indicate progress during normal operation.

[StefanKarpinski]

I'm not sure that Pkg3 should actually use the logging system for its output. Some high-level info, sure, but a lot of what it outputs is just eye-candy to give the user a good feel for what's going on. Then again, info like "this package was upgraded from this version to this version" are things one might want to log, but I feel like that might want to be a separate log stream that's intended for machine consumption instead of human consumption.

[c42f]

I thought about this quite a bit as I developed the system, for example inspecting how systems like Pkg2 and Documenter communicate with the user. The conclusion I came to so far is that logging can be a good choice for this kind of progress reporting. In particular

• Updates come incrementally and represent the state of the program.
• Some events may have state which would be interesting when debugging, if only it could be captured in something other than text.
• If someone uses Pkg3 as part of a larger application, they may want to silence the output or only print warnings, etc. They need more than text for this.
• For people using graphical IDEs, having only plain text to work with is a shame. It would be nice if they could systematically collect and format the output in a way which is more powerful than simple text.

The main difficulty is giving enough formatting control to make the output readable, hence the idea that the message should be interpreted as markdown, and my initial efforts to make formatting not suck by reducing the left hand margin to fixed width and right justifying the metadata.

It's also worth noting that there's a rather big difference between Pkg3 as the application vs Pkg3 as a library. If you're willing to spam stdout, you're thinking of Pkg3 as the main application. When it's a library it should not do so. This is a difficult conundrum, but I think it's solvable: As an application (eg, in Pkg repl mode) it should be free to install a custom Logger which prettifies the log messages. As a library, it should allow the larger application to control the output.

[StefanKarpinski]

Brilliant! I'm completely sold. It will be some work to integrate, but since it "only" affects interactive experience, it seems like fair game to work on post-feature-freeze.

[c42f]

Perfect! That's my hope regarding feature freeze - that the less "featury" of the changes implied by the logging work could be done in the cleanup period :blush: see #25109.

[c42f]

Fixed in #25488 / #25370