# 2024-01-15 Nix team meeting minutes #115

**URL:** https://discourse.nixosstag.fcio.net/t/2024-01-15-nix-team-meeting-minutes-115/38297
**Category:** Nix
**Created:** [January 15, 2024, 3:49pm UTC](https://discourse.nixosstag.fcio.net/t/2024-01-15-nix-team-meeting-minutes-115/38297 "2024-01-15T15:49:47Z")
**Posts on this page:** 1
**Page:** 1

<div class="post-metadata">

### Author: ![thufschmitt](https://discourse.nixosstag.fcio.net/user_avatar/discourse.nixosstag.fcio.net/thufschmitt/32/202_2.png) [@thufschmitt](https://discourse.nixosstag.fcio.net/u/thufschmitt)
#### Post date: [January 15, 2024, 3:49pm UTC](https://discourse.nixosstag.fcio.net/t/2024-01-15-nix-team-meeting-minutes-115/38297/1 "2024-01-15T15:49:47Z")

</div>

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

- Semantic overlap between the different kind of installables:

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`

- @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?)

- 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 `^`

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

- @ericson2314 opened [New derivation-making builtin · Issue #9774 · NixOS/nix · GitHub](https://github.com/NixOS/nix/issues/9774) 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)