2023-08-11 Nix team meeting minutes #79

Development Nix
1

Attendees: @edolstra, @ericson2314, @tomberek, @roberth

Triage and discussion

Add nix search --all by sophrosyne97 · Pull Request #4809 · NixOS/nix · GitHub

  • @edolstra, @roberth prefer the math simplicity of current implementation
  • @tomberek: probably bigger issue is forgetting to specify the flakeref
  • @edolstra: let’s close or postpone
  • @ericson2314: It seems what is what is actually bugging people is that control-C is not working well (a separate issue). So they accidentally spam their terminally with a huge list of packages and then cannot easily get out of it. So if we solve that problem (fix C-c, page output) then this won’t be so bad.

Decision: close

https://github.com/NixOS/nix/pull/5967

  • @ericson2314: Rather have this be a flag. Just pinning it on some env var which was until now a Nixpkgs-only thing (despite the name) doesn’t seem right.

    • Rather have it be a proper flag

  • @edolstra: Can use preHook it runs pretty early

    • @ericson2314: Well, when one is debugging and feeling confused what is going on, it one wants to see everything just to rule it out.

`nix flake update --single <name>` is more intuitive than `nix flake lock --update` · Issue #5110 · NixOS/nix · GitHub

  • @thufschmitt (through agenda): Old issue that never got solved. We have a sensible proposal and someone willing to implement it. I say go for it!

--all

-C and meaning of positional arguments

  • @edolstra, @tomberek: dynamically interpreting positional argument one would be ambiguous
  • @roberth: nix update instead of nix flake update so that we have an excuse to diverge from the “arguments are flakerefs” convention
  • @edolstra: Avoid -C because it’s inconsistent with the rest of the CLI
  • Preliminary conclusion: no changes then?
  • @tomberek: Can we acknowledge there’s a UX issue?
  • @tomberek: Switching between nix flake update and nix flake lock is counterintuitive

Locking flags on all flake commands

  • @ericson2314: Don’t all commands support --update-input?
  • @edolstra: Yes, except nix flake update, because it’s equivalent to --recreate-lock-file, so --update-input would be meaningless
  • @ericson2314: Flags should be adjectives/adverbs not verbs
  • @edolstra: However users expect nix flake update to have a flag to update just the specified inputs (e.g. --single)

Brevity and lock command expectations

  • @roberth: I think this is a (rare-ish) case where the UI brevity is actually really important, so we should consider nix update as an alias for the very specific behavior that people want but is not consistent with the otherwise verbose CLI conventions
  • @ericson2314: Can we sidestep the issue by reconsidering the basics, verbs, adjectives
    • Also, looking at the implementation I see removeFlag
    • @edolstra: Well, some commands don’t make sense with certain global Flake flags.
    • @Ericson2314: I don’t disagree, but I think this is a problem we should be having – if we have to filter-out global flags, this is evidence those should have never been global flags to begin with.
      • @edolstra: This is a side-effect of nix flake update being a shorthand for --recreate-lock-file. Normally you would never pass --recreate-lock-file --update-input ....
  • @edolstra: --update-input is a bit weird to have in all commands, but --override-input is rather useful
  • @edolstra: --update-input could be removed from the global flags
  • @roberth: --override-input is like --with-overridden-input but less verbose
    • @ericson2314: +1
    • @ericson2314 & @roberth: conversely the persistent side effect ones (such as --update-input) don’t make sense as --with-.... This is good evidence that they don’t belong there! (and just belong on update/lock).
      • hypothesis: the non-adjective/adverb ones that cannot be rephrased (e.g. with --with-...) are the sketchy ones which need to be filtered out today with removeFlag!
3 Likes