Add builtins.debug

[gytis-ivaskevicius]

When working on tests I thought that it would be useful to have some sort of logger which would be enabled by increasing verbosity level. This PR adds builtins.debug which evaluates the first argument when -vv is specified.

Exact use case:
I and @blaggacao started working on these check utils https://github.com/numtide/flake-utils/blob/master/check-utils.nix and plan is to add this kind of logging to simplify the debugging process for the end-users

PS: Please be gentle, I don't do CPP :D

[blaggacao]

LGTM (no CPP)

[gytis-ivaskevicius]

I'd appreciate a review.
\CC: @domenkozar @edolstra @regnat

[edolstra]

LGTM. Only problem is that the name debug is a bit generic...

Could you add a test?

[gytis-ivaskevicius]

Does anyone have any naming suggestions?

[HaoZeke]

pesticide --> bugnixer ?

exprval spewlvl

[L-as]

builtins.traceVerbose?

[infinisil]

I think @L-as's suggestion of builtins.traceVerbose is great. In addition to the below suggestions, I'm not entirely sure whether using -v for this is a good idea, though I don't have any good reasons against it.

Here's a branch where I implemented the below two suggestions (and also having a separate flag instead of -v, but not sure if we want that): infinisil@3cfde43

[balsoft]

I like the idea, as long as you can't "lift" the verbosity level to the Nix language itself.

[gytis-ivaskevicius]

Finally got around to this. I think its ready for review

[infinisil]

Yeah, I think it's fine. Does not really matter.

I think this does matter, why shouldn't it? This isn't an implementation detail, this is the user interface. It's the difference of requiring the user to learn an extra flag, or being able to reuse -v. On one hand, I don't see any problems to reuse -v, but on the other hand it seems cleaner to have this separate --trace-verbose flag, especially because the -v flag currently doesn't involve evaluation at all.

So I guess I'm leaning towards having the new --trace-verbose, but I'd like someone else to think about this.

[gytis-ivaskevicius]

Alright, I would prefer -v. Definitely not a deal-breaker for me. Does anyone else have any thoughts on this?

[roberth]

Regarding -v/--trace-verbose: I think this can be decomposed into a more general problem.
In any sufficiently complex system, it's nice to be able to set verbosity at a component level, similar to how verbose kernel logging doesn't add extra data to my web server access logs. It seems like a perfectly sensible request to only log verbosely in certain components, such as one of:

• Nix expression trace calls
• evaluator
• store operations
• substitution
• sandbox
• NIX_DEBUG in derivations
• user code (evaluation + NIX_DEBUG)
• Nix expression trace calls, restricted to certain flakes

If this feature was implemented, it'd subsume --trace-verbose and probably provide it as a more systematic flag.
So let's not get ahead of ourselves and pick -v for now.

[roberth]

This also reminds me of NixOS/nixpkgs#140763, which makes lib.warn abort. It'd be great to have this behavior as a builtins.warn, which then also works in pure mode.

(A --show-trace-on-warn would also be great but is just not feasible without having traces as first class objects. Stackless evaluator? Would be cool but not a priority.)

[infinisil]

@roberth --show-trace-on-warn could be feasible if there was a builtins.warn

[roberth]

@roberth --show-trace-on-warn could be feasible if there was a builtins.warn

Do we have first-class traces yet? Afaik, they're hidden behind the implicit C++ exception stack. Otherwise, realistically, we can only do --error-on-warn.

[infinisil]

This is related to #749, ping @Profpatsch

[Profpatsch]

I don’t see how it’s related to displaying warnings.

Warnings should show even if the user does not use -v, cause otherwise they will miss them during normal use of nix.

[infinisil]

I think it's related because of different verbosities of messages:

• Error (maybe throw, though that stops execution)
• Warning (The thing discussed in Semantically meaningful ways to communicate our intent #749)
• Info (builtins.trace)
• Debug (builtins.debug, this PR)

[Profpatsch]

At this point I have lost hope that nix will ever have a sensible way of displaying warnings tbh. The hydra and nix-env misdesign won’t be changed according to upstream, so there’s just no real way to make it work.

[edolstra]

@Profpatsch What misdesign are you referring to?

[thufschmitt]

@edolstra @gytis-ivaskevicius : apart from the (small) merge-conflict, anything preventing this from being merged?

[thufschmitt]

@gytis-ivaskevicius I’ve merged the branch with master, but now the build is failing. Can you have a look?

[thufschmitt]

We discussed that a bit during the last UX meeting. There's a broad consensus on this being great, just needs to fix the build.

@gytis-ivaskevicius think you can take a bit of time to do that?

[gytis-ivaskevicius]

Alright, will do! (Expect a push tomorrow/day after tomorrow)

[gytis-ivaskevicius]

Sorry, a little late. Took me 2 attempts to resolve the issue 😅

[thufschmitt]

Thanks, let's roll this!

[thufschmitt]

Thanks, let's roll this!

Once the CI agrees, that is

[thufschmitt]

Duh, forgot about the release notes. I'll add them in another PR