2024-01-30 Nix team meeting minutes #119

Release 2.20

Good to go

#912 allow leading period by roberth · Pull Request #9867 · NixOS/nix · GitHub


Allow gc-ing with a rootless daemon by thufschmitt · Pull Request #5380 · NixOS/nix · GitHub


CLI stabilisation

Auto-gc policy: Make 'nix store gc' use the auto-GC policy by edolstra · Pull Request #7851 · NixOS/nix · GitHub

Slow progree, @edolstra will keep working on it

`nix hash path`, text hashing for `nix store add`, and preparatory refactors by Ericson2314 · Pull Request #9815 · NixOS/nix · GitHub

Assigned to @thufschmitt for review

Triage and break up the global settings · Issue #5638 · NixOS/nix · GitHub


nix copy: nix-push was removed without a stable replacement · Issue #8011 · NixOS/nix · GitHub


nix help-stores

Still exists, spits out the documentation for all the stores

  • @ericson2314 Could just show the documentation for the current store, maybe in nix store info
  • @tomberek, future work to allow store-specific settings to be defined in config and addressed by alias

Not a blocker for the initial batch

nix path-info

  • @tomberek: Doesn’t currently cover all the use-cases of nix-store --query

    • Do we want path-info to be the equivalent of nix-store --query?
  • @roberth: Three kind of queries:

    • One-path only
    • Closures (can be slow)
      • graph
      • closure size
      • why-depends (?)
    • Reverse-closures / entire store
      • e.g. referrers
      • derivers
      • roots
  • Translating that in term of CLI commands

    • One-path commands could be part of path-info
  • @ericson2314 doesn’t like path-info because it is about store objects not store paths.

    • nix object-info
    • nix store object info
    • nix store object-info
    • nix object info, nix object sub-command in general?
      • nix object add?
    • nix store-object (annoying with shell completion; extra step for space vs -)
    • “store object” is a lot clearer than just “object”
  • @edolstra: I’m against using “object” in the CLI, nobody knows what an “object” is in the context of Nix.

https://nixos.org/manual/nix/unstable/json/store-object-info newish documentation trying to group the current fields. ← should be “store path info”

  • It’s unclear what are the roles of fields (to new/intermediate users esp.)

  • for content-addressed fundamentally many to one (including none at all for sources)

  • For input-addressed actually do have a canonical answer, and somewhat important to verify the store pathy

  • @roberth: Group metadata about the realisation together, e.g. ?

    • build.deriver
    • build.time (TBD)
  • Store-specific state?

    • store.registrationTime
    • store.lastVerified (TBD)
    • store.signatures
  • 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?)

    • narHash
    • narSize
    • path
    • references
    • ca
  • Meeting ended

  • @roberth: Not sure if this needs to be a change in the format. It doesn’t violate a CLI JSON rule and this could also be documentation. Opportunity cost is real.

  • @ericson2314: Grouping is good. Easy, and still a crucial small hint ot the user

  • @roberth: Groups can be used for enable/disable on the CLI

    • especially relevant if we include relations and closure properties in the same command
  • @roberth: More questions for next time:

    • Should closure properties be computed for each output item, for each argument, or only for the whole invocation? Per item seems too expensive (and O(depth²) verbose).
    • Separate commands or boolean flags to include more info?
  • “query” use-case: Haskell for all: How to correctly cache build-time dependencies using Nix

    • @roberth: could be covered by options (--output-store?), but is a good use case for validating the completeness and (to a degree) usability of the solution.