2023-09-04 Nix team meeting minutes #85

fricklerhandwerk · September 4, 2023, 7:46pm

Attendees: @roberth @regnat @ericson2314 @fricklerhandwerk @edolstra @tomberek

Agenda

Updates
Stabilisation

Updates

@fricklerhandwerk invites Nix developers to the 23.11 ZHF hackathon and developer workshop in Zurich end of November
Briefly brought up the topic of funding particular areas of maintenance again
- @fricklerhandwerk will make a project draft for the team to review
We will skip meetings on 2023-09-08 and 2023-09-11 due to NixCon
- @edolstra @regnat @tomberek @roberth @fricklerhandwerk will attend

Stabilisation

Opened issues on missing items:

`nix store delete`

discussed the distinction between handling “low-level” store paths vs. taking installables
- @roberth argues there is ambiguity if a symlink resolves to a store path that contains a flake
  - @tomberek: currently the behavior is that the store path property takes precedence
- @edolstra: may require more cleverness from the commands to figure that out
  - @fricklerhandwerk: arguably low-level commands should not be clever, we should move that up a layer
    - we discussed having top-level commands that do “the right thing”
    - @edolstra: how would users know which of two very similar commands does what they want?
  - @ericson2314 already invested quite a lot of time enabling low-level commands taking arbitrary installables, and so far the paradigm was that all commands would accept both high-level and low-level references
  - @edolstra: we shouldn’t make a distinction between porcelain and plumbing
    - although nix store delete is probably nothing you’d use every day
    - @ericson2314: porcelain-vs-plumbing is a more universal UI principle we should take into account
    - @edolsta: git also has this distinction, but its plumbing commands accept all the types, refs, revs, …
- @edolstra: the store symlink is an edge-case we may actually support
  - parsing installables is the only thing that has ambiguity, and it can be alleviated by adding options to make this explicit
- @fricklerhandwerk: another way of resolving the ambiguity is just documenting the precedence of store paths
  - @edolstra: nix-store has the same behavior, changing it would be a new feature
    - @roberth: it’s a non-issue for nix-store
  - @tomberek: propose to keep the existing behavior rather than addressing the issue, for now
  - @roberth: could also error out if we don’t want to decide it yet
does stabilisation require handling this?
- decision: yes

`nix store repair`

question: should both nix store repair and nix build --repair exist?
@roberth: proposal to mark broken store paths
- Check asynchronously that build dependencies aren't corrupted · Issue #8656 · NixOS/nix · GitHub
postponed for now

`nix store sign`

@tomberek made a little survey on the issues with signing: Unsigned derivations uploaded to S3 · Issue #6960 · NixOS/nix · GitHub
@ericson2314: should sign everything by default
@tomberek: it get’s even more complicated with layered stores
@roberth: require a flag for now before we make a final decision on defaults:
- nix store sign (--single|--recursive) <installable>
@roberth: should instead read keys from stdin, more secure
- @tomberek: --key-file - could exclude installables from stdin
- @fricklerhandwerk: then installables should be read linewise from a file, e.g. --from-file <(...)
- We need two streams, one for keys, one for the installables.
will pick it up again next time