2024-01-15 Nix team meeting minutes #115

Development Nix
1

Attendees: @roberth @edolstra @ericson2314 @tomberek @thufschmitt

CLI stabilisation

TL;DR of the decisions:

  • File installables
    • @thufschmitt will draft a document listing all the proposals for the file installables syntax, give the team 1 week to review it and throw it in a public place (discourse or GH issue) asking people to discuss it. The the team has until Feb. 16 to make a decision on the final syntax, and we can implement it for 2.21
  • Expr installables
    • Unless that’s not applicable, the syntax will just follow the one used for files
  • Output selection
    • Use .{outputName} to access specific outputs following the Nixpkgs convention (already works)
    • Add a .derivation output to Nixpkgs’s stdenv output, to be used as the standard convention for getting the derivation (@roberth)
      • foo.derivation should be an opaque store path referring to foo’s deriver
    • Make .drvPath work the right way™ by making Nix happy with DrvDeep installables (upcasting them them to plain store paths), with a warning (@Ericson2314)
    • Have ^.. as the low-level way to access the deriver of an installable that always works (@Ericson2314)

Installables

  • @roberth: We should start stabilizing that right now as most commands require them

  • We can leave aside the flake installables for the moment

  • @roberth different installable types map to different data types, and each command can work with different kind of things. We need to make this many-to-many relationship explicit

    • In the documentation: say what is expected from the installables
      • e.g. if it must be a flakeref, document the args as “flakerefs”
    • How do the conversions work? For instance some commands expect store paths. How are packages mapped to store paths? Or flakes? Is a .drv special?
    • How to specify installables unambiguously, e.g. when scripting and the script knows the “type”: how to avoid accidental misinterpretation?

  • Semantic overlap between the different kind of installables:

    • Is this something we’re OK with?

Currently nix build nix will build the default output of the nix flake, unless the current directory has a nix symlink pointing to a store path

Store path installables

Currently:

  • Relative paths are interpreted as store paths if they are symlinks to store paths, although they are also valid flakerefs
  • If a store path contains a flake.nix, ambiguity as to whether that should be a flakeref or a store path installable
    • Currently it’s a flakeref, but probably not the right behavior (EDIT: Actually not, except for flake-specific commands)
    • Esp. since we can force it to be a flake, but not the other way round

File installables

  • @Ericson2314: --file is not good enoguh

  • @edolstra: let’s have --flake, --file, --storepath to complete the symmetry

  • @roberth: a “stateful” style command line allows terseness even when multiple isntallables are needed, while also allowing combinations, such as
    nix build --file default.nix attrA attrB --flake nixpkgs#hello

    • it’s compatible, unless --file happened at the end

  • @thufschmitt: There’s a lot of possibilities, with no clear best option. How about we list them in some public place and find a time-boxed procedure to decide (voting?)

    • Plan: @thufschmitt will draft a document listing all the proposals, give the team 1 week to review it and throw it in a public place (discourse or GH issue) asking people to vote for their favorite.
      • How do we decide the truth?
      • Deliberate, and deadline for Feb. 16

  • What about pure-mode files? Currently triggers pure-eval = false

Expression installables

We’ll settle the syntax for file installables, and align the expr one on it (as much as possible).

Output selection / ^ interaction (the outputOf caret)

  • @Ericson2314 is concerned about interaction between caret and coercions on the left size

  • @roberth is ok with it as long as the coercion happens on the left hand side and isn’t customized to ^

    • Installables perform coercions such as flake → package and/or package → store path. ^ requires a store path from the installable (and returns a store path)

  • Not sure how to handle that for non-store-paths atm (should nixpkgs#hello^out work, or should it be nixpkgs#hello^..^out?)

    • @roberth: the latter is more consistent, which is a priority for low level tools
    • @ericson2314: a coercion could be added later, but is hard to remove

  • @ericson2314 opened New derivation-making builtin · Issue #9774 · NixOS/nix · GitHub for general problems with builtins.derivation and hopefuly mkaing a replacement

Plan:

  • Use .{outputName} to access specific outputs following the Nixpkgs convention
  • Add a .derivation output to Nixpkgs’s stdenv output, to be used as the standard convention for getting the derivation (@roberth)
    • foo.derivation should be an opaque store path referring to foo’s deriver
  • Make .drvPath work the right way™ by making Nix happy with DrvDeep installables (upcasting them them to plain store paths), with a warning (@Ericson2314)
  • Have ^.. as the low-level way to access the deriver of an installable that always works (@Ericson2314)
2 Likes