2023-12-08 Nix team meeting minutes #110

tomberek · December 11, 2023, 1:19pm

2023-12-08

Backport of a pure refactoring
- @edolstra: Kinda scary because it’s a big change
- @thufschmitt: We could backport it when/if needed, but shouldn’t do that eagerly
- Agreement on closing the PR until we need it

Warn people when they use an old version.

@edolstra: Can be very annoying for people although their Nix works fine otherwise
@roberth: If you’re stuck with an old Nix, you’re asking for trouble, and you should opt into that explicitely
Needs further discussion

New store type that stores the metadata in json files rather than an SQLite database
Use cases
- layered/key-value filesystems (OCI, ZFS, S3)
- Easy to diff and test changes
- Agreement on merging the refactoring parts and keep the store implementation itself out of tree

Deferring triage until issues mentioned async are fixed.

Goal: Do more development-related work in addition to maintenance

@roberth: We need to do something to keep track of what’s in the way of our projects, in particular flakes stabilisation

The team will block 1h next monday to triage the flakes and new-cli issues and see which ones are blocking the stabilisation

@ericson2314 less special syntax in the CLI would be better
proposal - someDerivation^.. is the drvPath as a store level operation
CLI behavior needs to be defined
NixStringContextElem::DrvDeep behavior?
- Ericson2314: just stop worry about that!
in a package where .doc is built by a different derivation than .out, we’ll want ^.. so we can do pkg.doc^.. to get the --derivation behavior for that output, but this is not supported in the CLI yet anyway.

(post meeting more discussion)

Can we defer some of this stuff for later? (e.g. ^..)
- yes
include examples in release notes
- nix copy --derivation
- nix why-depends --derivation
- nix path-info --derivation
- "${lib.getExe nix} ${lib.optionalString (lib.versionAtLeast nix.version "2.21???something") "--derivation "}"