Is Json a better name, because it's in a Json format?

Fair point. Can we agree on minimal-json though? That's IMHO better to make it distinguishable from internal-json (which I intentionally didn't choose as it basically puts the entire, pretty-printed error into a JSON).

cc @edolstra WDYT?

I don't really understand why we need another JSON output format when we already have one. What information can't you get from the existing format?

@edolstra the current json format returns a fully detailed message containing code-lines etc. This is IMHO fairly hard to parse for editor-plugins where I only need the line-number, line-column and message (which is provided in single JSON-fields in my new logger).

Also, we probably want to use the full-blown human-readable message in the internal-json logger (AFAIU) since that's how log-messages are received from a remote builder.

Finally, the internal-json logger is subject to change between releases (according to the man-pages) which would mean that plugins have to be modified for each new Nix release (in the worst case).

I see two options to take care of it:

• provide another logger for the purpose I described (which is currently the case in this PR)
• modify the internal-json logger to define (1) a somewhat stable structure and (2) expose error-msg (without code-lines), line-nr and line-column as additional json fields.

I'm fine with either of those options, so feel free to decide which you prefer.

cc @bburdette who also might be interested in reviewing this as they implemented the beautiful new error-messages.

I think it's better to improve the existing JSON logger than to add another one. The whole point of the JSON logger was that it's the last logger we'll ever need, since it should provide all information in a format that other tools can easily process.

Finally, the internal-json logger is subject to change between releases

I don't think that should be the case. Having a log format that can change in arbitrary ways is not very useful. I think it's more that clients should be prepared to handle message types or fields being added or removed. (Conversely though, who says that the a new logger wouldn't be subject to change?)

Also, we probably want to use the full-blown human-readable message in the internal-json logger (AFAIU) since that's how log-messages are received from a remote builder.

No, the daemon should send structured error messages to the client. Currently errors from the daemon don't get formatted very well. For instance, the daemon doesn't know the terminal width of the client. And it's hard for the client to add context to an error received from the daemon.

modify the internal-json logger to define (1) a somewhat stable structure and (2) expose error-msg (without code-lines), line-nr and line-column as additional json fields.

I think this is the best approach. The code lines can probably be put in a separate JSON field which tools like IDEs can ignore.

Conversely though, who says that the a new logger wouldn't be subject to change?

Well, first of all it was explicitly stated in the man-pages. Also, error-information is only provided in the msg field which can be an arbitrary string (which is in this case a problem as we'd currently have to parse e.g. line-numbers etc. from it).

I think this is the best approach. The code lines can probably be put in a separate JSON field which tools like IDEs can ignore.

That's also perfectly fine for me. I'll update the PR later today, thanks for your feedback!

@edolstra updated accordingly %)

Maybe take a look at what i wrote in #3841 ? I think this separation of rendering and data would also be good for machine-readable logging; currently we bake a lot of data in the hint which is conceptually separate, and should be actually separate for machine-readable logging.

I like it! I could see adding the trace info into the json format if at some point there's a tool that needs it.

@bburdette fair point, added traces as well.
@Ericson2314 AFAIU this is something where we'd have to refactor the error-API first, right? After reading through the issue I'd generally agree with you, but this seems slightly out of scope for this PR (unless I misunderstood your point).
@edolstra anything else tbd? :)

Yes I suppose this changes are independent of this PR.

afaics all comments are resolved. Anything else to add @edolstra?

ping @edolstra anything else tbd to get this merged?

ping @edolstra @Ericson2314