2024-03-11 Nix team meeting minutes #132

thufschmitt · April 8, 2024, 3:27pm

Triage

Still a WIP
Remote builder format suboptimal. Attempt at improving the internal representation and data model.

Already agreed this was something we wanted provided it’s not too intrusive. And that one isn’t, so that’s cool
@roberth will look at it
- Will need a test
- Seems surprising and concerning that it works at all
- Appears to rely on alternative Nix code path that accesses worktree files directly. We should probably not do that.

root or write-access to /nix/store will bypass daemon
Needs to benchmark a bit to show the performance impact on things like nixos-rebuild

[@tomberek]: Deferring to @pennae to know whether that should wait until the parser rewrite is done

nix eval should print drvPath instead of infinite looping
@roberth: It just does too much. There’s no need to recurse into everything. Print a single Value only?
@tomberek: Should it be drvPath?
- outPath would be more consistent, but sometimes non-existent
Approved, but needs a release note (and a test)

@roberth: Makes errors distinguishable in-language, exposing evaluation order, etc, by doing string matching etc.

How can users know that there’s more to the error?
How do they get the whole message? Getting the attribute by hand could be annoying.
Potential alternative design: Print the errors at the end like footnotes or interactively

nix-repl> foo
{ foo = <<error, see :error 1>>; bar = <<error, see :error 2>>; }

nix-repl> :error 1
This
is
a
long 
message

For top-level errors, print the whole thing, as before.

If the top-level thing is a package, make sure it also prints the whole error, as before.

We’re getting stuck on the day-to-day again
- How can we make sure we stick to our stated objectives?
Tried to raise contributions around the CLI in the past with mixed success
- Maybe announce on discourse? An ongoing thread in the style of Nixpkgs PRs ready for review.

Make `builtins.fetchTree` return a path as its `outPath` element · Issue #10115 · NixOS/nix · GitHub
- proposal to change output type to “path” vs “string w/context”
“virtual strings” - lazy strings
proposal: lazy paths
- lazy-trees support for paths without support for laziness in strings
- fetchTree
- interpolation name of a lazy-path == “source” or the name, only at the root
explore “lazy paths”
- Is it feasible to implement?
- Does it differ from lazy-trees, and how?
- Reconcilation? Bad to end up with another kind of laziness
  - If the changes are part of lazy-trees (prev question), this is not a problem
- Does this end up being useful in practice?
- Module system error messages show path to module
  - just to print error message
  - paths sometimes used as attrset keys
- dirOf changes
- determine if this causes Nixpkgs/NixOS hash changes
- timebox (<1 week)
- there is a branch that has much of this
- … coordination …
- perform Nixpkgs+FlakeHub regression tests
alternative: __toString in fetchTree return value
- too awkward?
alternative: addToStore can detect and prevent double-copy
- cons: likely historical hash changes
  - maybe detect special “lazy path” case? seems too ad hoc
- pros: consistency
alternative: keep output as string
- requires “virtual strings” to be performant
  - strings with a lazy-path context