2024-02-12 Nix team meeting minutes #123

Attendees: @Ericson2314 @edolstra @roberth @tomberek @pennae @thufschmitt

Continous benchmarks

Restore `builtins.pathExists` behavior on broken symlinks by alois31 · Pull Request #9985 · NixOS/nix · GitHub

deduplicate inherit-from source expr work by pennae · Pull Request #9847 · NixOS/nix · GitHub

parser rewrite by pennae · Pull Request #9989 · NixOS/nix · GitHub

  • Confirmed something we want. Still blocked on other stuff

improve error reports somewhat by pennae · Pull Request #9874 · NixOS/nix · GitHub

Add sandboxed building for FreeBSD using jails by rhelmot · Pull Request #9968 · NixOS/nix · GitHub

Getting more maintainers

  • @thufschmitt: People like @pennae or @999years are very prolific and high-quality contibutors and could be “raised” into maintainers

  • @edolstra: No objection to people reviewing things, but merging them should be the responsibility of the maintainers team

  • @pennae: Things reviewed by others should be merged then

  • @ericson2314: Out of capacity for reviews. Need to grow the team

  • @edolstra: Not in favor of growing the team atm. Adding maintainers who can review things sounds good though.

  • @roberth other strategies

    • Getting funding to allow the maintainers to spend more time on it
    • Improving the process
    • Specialization of maintainer responsibility / ownership
  • Proposal (@thufschmitt): Formally set a group of people that we trust for reviewing stuff.

    • Codeowners would be nice, but requires commit access
    • First step: Add people to the nix-issue-triage GH team and trust their reviews
      • Not perfect because won’t allow running the CI for new contributors or making approvals show-up as approving the PR, but first step
    • Can add @pennae and @9999years at least
    • Agreement

CLI stabilization

nix path-info

Previous proposal: Split the output into sections, but no agreement on what the sections should contain.

Minimum set of fields that stay the same on copy (not sure if we want to promise this, but seem to follow the rule) (same set as exportReferencesGraph?)


Group metadata about the build together, e.g. ?

build.time (TBD)

Store-specific state?

store.lastVerifiedTime (TBD)
  • @edolstra: Not that many fields that we need to namespace them
  • @pennae: Namespacing doesn’t hurt, why not just do it?
  • @edolstra: Would break backwards-compat. Can be fine, but needs to be justified

nix-store --query alternative

  • @tomberek: How to do: Haskell for all: How to correctly cache build-time dependencies using Nix

    • Have a recommended way to provide the information commonly needed and served by “–query”
      • runtime closure + sizes
      • buildtime closure
      • runtime of the build closure (–include-outputs)
        • either intersected with current store state or not
      • referrers
  • possible query language for full-generality?

    • would have to be similar to a graph database ql
    • may not perform well on stores such as binary caches
      • though we do have a narinfo cache
  • Proposal (@thufschmitt):

    • Align the json and no-json outputs to always display all the (non-computed) output fields
    • Have a --recursive flag to work on the whole closure
    • Rough agreement

What about the reverse closure?

  • Not part of nix path-info atm. But we’ll probably want it in the new CLI
  • @roberth: From experience, virtually always used to debug, for delete / gc
  • Can leave it out for now, if people want it in the new CLI, they can add a feature-request for it

Relationship to nix why-depends?

  • nix why-depends is a porcelain command, building on top of the same features as path-info, but different from it

  • @Ericson2314: I don’t really like the ValidPathInfo data type, which is the main purpose of this command. I also don’t like the path-info name, because the information is about the store object not the mere path that refers to it.

    This actually works out nicely in a way. We seem to agree this command doesn’t sit perfectly with us, and the name doesn’t sit perfectly with me, so if we stabilze this as is, we’re in effect “saving a better name” (that we have yet to pick) for a better command we have yet to invent.

    This is nicer than having the “bad command” steal the “best name”

For the future: Flesh out issues for contributors to work on


Wow, so many exciting improvements happening! As someone who doesn’t follow Nix development closely, thank you very much for the digest :slight_smile:

1 Like

Yes, thanks a lot for the notes. I am always interested to hear what the Nix team does.