Release 2.20
Good to go
#912 allow leading period by roberth · Pull Request #9867 · NixOS/nix · GitHub
https://github.com/NixOS/nix/pull/9867#issuecomment-1923537311
Allow gc-ing with a rootless daemon by thufschmitt · Pull Request #5380 · NixOS/nix · GitHub
https://github.com/NixOS/nix/pull/5380#issuecomment-1923539914
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
https://github.com/NixOS/nix/issues/5638#issuecomment-1923556646
nix copy
: nix-push was removed without a stable replacement · Issue #8011 · NixOS/nix · GitHub
https://github.com/NixOS/nix/issues/8011#issuecomment-1923561614
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 ofnix-store --query
?
- Do we want
-
@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
- One-path commands could be part of
-
@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.
-
@roberth: could be covered by options (