[Nix#9942] Better support for printing large values in nix repl
and error messages #61
Labels
No labels
Area/build-packaging
Area/cli
Area/evaluator
Area/fetching
Area/flakes
Area/language
Area/profiles
Area/protocol
Area/releng
Area/remote-builds
Area/repl
Area/store
bug
crash 💥
Cross Compilation
devx
docs
Downstream Dependents
E/easy
E/hard
E/help wanted
E/reproducible
E/requires rearchitecture
imported
Needs Langver
OS/Linux
OS/macOS
performance
regression
release-blocker
RFD
stability
Status
blocked
Status
invalid
Status
postponed
Status
wontfix
testing
testing/flakey
ux
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: lix-project/lix#61
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Upstream-Issue: NixOS/nix#9942
Is your feature request related to a problem? Please describe.
Currently, some error messages will print values in a "limited" fashion, after PRs like #9753. Using the value printer refactor from #9606, Nix will print at most 10 attributes, 10 list items, and 1024 bytes of each string in error messages before giving up and printing a message like
«20373 attributes elided»
to indicate the missing values:nix repl
doesn't currently use this output-limiting functionality, but instead sets a maximum depth (of 1 level) to print to, with the:p
command used to print the entire structure:But the maximum depth of 1 still produces virtually unbounded output for large flat attribute sets like
nixpkgs
. EvaluatinglegacyPackages.aarch64-darwin
innix repl nixpkgs
will happily spend 4 minutes printing 400,000 lines of output, and from experience seems rather uninterested in stopping when Ctrl-C is pressed.Describe the solution you'd like
I would like to set
nix repl
to pretty-print (as in #9931) a modest number of maximum attributes, list items, and strings. The printer will track if any values were omitted, and this information will be used to format a tip for the user. Roughly like this:(NB: In practice, we'd want to print a decent amount of attributes, maybe 100, before eliding any.)
Combined with #9922 and #9944, we could also add a REPL command to change the maximum values to be printed at runtime:
This could be used to improve error ergonomics as well, by providing an opt-in for printing more of failing values:
Additional context
Why does this functionality require setting handlers (#9922)?
It may not seem obvious, but this functionality requires setting handlers (#9922). This is because C++ initializes
static
values in an arbitrary and undefined order before executing themain
function. Inprint-options.hh
, we have some code like this:If we naïvely added a setting like this:
And updated the
errorPrintOptions
definition to match:Then the compiler may very well decide to initialize
errorPrintOptions
beforeevalSettings
, leading to zero attributes being printed in error messages. (Worse, the compiler could initialize the twostatic
s in different threads, leading to a non-deterministic number of attributes being printed.) With a setting handler, we could ask themax-attrs-print
setting to simply updateerrorPrintOptions.maxAttrs
when it's set.The alternative, which I think is probably a good idea regardless of whether settings handlers are added, is to make setting values (and many other
static
s in the Nix codebase) functions, so they run in a predictable, programmer-controlled order, from within themain
function.Priorities
Add 👍 to issues you find important.