2024-02-26 Nix team meeting minutes #128

Development Nix
1

Agenda

  • Triage (30 min)
  • TH: Board situation
  • TH: CLI stabilisation

Nix 2.20 stops working with git lfs · Issue #10079 · NixOS/nix · GitHub

`builtins.toJSON` impossible to create single backslash followed by certain characters · Issue #10082 · NixOS/nix · GitHub

File flake input broken in latest git version · Issue #10080 · NixOS/nix · GitHub

Assigned to @edolstra

WIP: literate repl tests by lf- · Pull Request #10075 · NixOS/nix · GitHub

CLI stabilisation

Nix build

  • What should it build? ie what’s the function Installable -> List DerivablePath

    • Same as all the other installable commands
    • nix build <stuff>^dev: has to be coerced to a (store) derivation, and build the dev o from it
    • nix build <package>: (type = "derivation")
    • nix build --expr [ path1 path2 ]: (e.g. nixpkgs#bind.all)
    • nix build /nix/store/….drv: just realise the .drv. If they’re using drv paths, we assume that they know what they’re doing. (and can use “^*” if needed)
    • nix build /nix/store/…: substitute the path. Use case: create a symlink.
    • nix build expr.drvPath: like a raw drv path. They put .drvPath for a reason.
    • nix build <language string>: (e.g. nixpkgs#hello.outPath)
      • Realise the string context
      • Restrict to single path? Yes.
      • Print the string to stdout? Different command for that?
    • nix build <path-like attrset>: (having outPath, not type = "derivation")
      • Coerce to path, and behave like nix build <language string>
      • Use case: hello.src where src = cleanSource ./.;
    • nix build <path value>
      • “Realise” by adding to store
    • nix build <language attrset>: (not type = "derivation")
      • Currently we fail
      • nix-build would build the attrValues, and respect recurseForDerivations (inserted by recurseIntoAttrs)
      • Maybe for legacyPackages only?
        • tomberek: Footgun, building the world
        • doesn’t solve the tests attribute use case (e.g. passthru.tests)
          • Add another marker?
      • Can’t rely on users to ^C and this runs the risk of failing with an unrelated build failure
        • edolstra: A better progress indicator could solve that. It could list the attribute paths as it encounters them.
      • Alternatives
        • Separate CLI command
        • List?
          • A more intentional way to build multiple. We don’t have oversized lists in the wild.
          • You lose the information to produce a meaningful symlink (except perhaps output names, although those are somewhat subject to change, given a language-based package output definition)
          • --apply will be helpful, but is a lot of typing and thinking for a quite common use case.
          • nix eval <attrset> | nix build --stdin
          • nix-eval-jobs <attrset> | jq | nix build --stdin
      • Decision: Keep the conservative statu-quo for now and fail
    • nix build <language list>:
      • nix build each item
      • Will be useful particularly with --apply
      • Another use case: pkg.buildInputs
      • If some elements aren’t valid installables, fail
    • nix build <other language value>: fail (e.g. bools, null)

  • User interface

    • --dry-run
      • Currently using the same interface as the old-style
      • --json is broken. Need to be fixed
    • --json. What should it print?
      Currently a list of installable serialisation
      • Proposal: split by installable and preserve structure. Example: nix build pkg1 path2
        { "paths": [ ... ],
  "installables": [
      { "installable": "pkg1", "type": "package", "paths": [ ... ], "outputs": { "out": ... } },
      { "installable": "path2", "type": "path", "paths": [ ... ] }
  ]
}
    • strive for similar output structure for “dry-run and json”
    • If dry-run, each path (... above) is a JSON DerivablePath. Otherwise it’s just a store path string.
    • It should be possible to resume the build from --dry-run (ignoring .drv gc roots perhaps)
    • tomberek: very similar to profile manifest. We could unify this.
    • roberth: Maybe add one or two fields (such as “type”)
    • tomberek: Also information that’s known after realisation, such as size, build duration
    • roberth: like sql-joining path-info

  • TBD Make symlinks more useful?

    • Idea build a more predictable symlink name e.g. result-<installable index>-<output name>
    • Proposal:
      • base is result (or the value of --out-link)
      • If multiple installables on the CLI, append -{index}
      • If list, append -{index}
      • If .drv with multiple outputs, append -{outputName}
      • If a package with multiple “outputs”, append -{outputAttrName}
    • Proposal: make the transition to multi outputs transparent
      • Example nix build bind
        • result: profile containing the bind package (buildEnv)
        • result-out: the out output of the bind package
        • result-dev: the dev output of the bind package
      • Only apply to packages (and derivations), not to multiple installables or lists
    • TODO: Open an issue about a --buildenv flag
2 Likes