Use the new Frames.hs mechanism for low impact tracing code as well

[jwiegley]

In addition using the new NixFrame type for evaluation and normalization contexts, also use them for simple tracing message so that -v5 can show what Nix is doing (for example, which files it's importing), even when there is no error that causes context to be displayed. That is, these frames would be rendered as they occur, rather than being stored and rendered later.

[Anton-Latukha]

So, in the end this seems to be intimately connected to #509, Frames and exception handling should end up together.

Recently the Frames were fixed: #760. Vaguely remember encountering that type collision in that place during exception poking around / trying to use Frames, so after the fix, thinking it should work now.

[Anton-Latukha]

so that -v5 can show what Nix is doing (for example, which files it's importing), even when there is no error that causes context to be displayed.

Is a light polite reference to the reinvention of message classification in Nix, the specification got fixated to have a case 5 or 6 levels of "Errors" messages only, without other message classification, which is a fatal design flaw of it, since in practice - the is no 5 levels of Errors, there are majorly only 1 level of Errors and a lot of Warnings, and Notifications, and a ton of normal and low-level debug messages.

afaik from my Nix learning, & usage & Nix/NixOS/NixOps DevOps exp - Nix almost never-ever uses that messaging classification, everything gets casted into 1 level, in my history I've seen 1 or 2 messages casted to other levels.

If reality Nix essentially fellback to proper solution - the SYSLOG (RFC 5424) standard that everybody implicitly intuitively know and use. I've written it in https://wiki.archlinux.org/index.php/Systemd/Journal. SYSLOG is industrial standard and systemd and many other systems (BSDs) also use it while others or use it also, or compatible with it.

The SYSLOG goes:

0. Emergency
1. Alert
2. Critical
3. Error
4. Warning
5. Notice
6. Informational
7. Debug

They have concrete definitions for very precise classification. For example: We, as all apps, are privileged to use only 7-3, IO Exceptions throw 3. Well, we can cast 2 and even 1 - but for those, we would need to have our own OS distribution.

What I propose is to, because Nix messaging classification does not work and not used - dedup it into industry-standard classification that everybody expects in systems.

So:

journalctl -p 5..3

equals

hnix -p 5..3

So if we run HNix OR look into journalctl - the logs would equal one another.

And then

hnix

Would produces 6..0.

And so -v1 gives the 7..0 - normal "seems good enough" depth of debug messages, and further, we can have as many -v.. debug layers as we want if we would ever want to have multiple levels of detail for debug messaging. This is how most *nix serious utils operate, ssh somehow comes to mind.

And I'd pushed a lot of stuff into debug layers by default. People do not need to look at gibberish scrolling walls of text all day if they do not need that info in front of their eyes, better provide good error context, and allow them to have a great exp digging into journal. HNix also reproducible, which means that if even they run something and want to look-up more info on something - we need to write into the system log, or anyway also they always can rerun the command and reproduce the same result.