[RFC] Initial Proposal for flake-parts-cli

[srid]

Rendered

• Transfer content from internal Slack
• In what ways, can we concretely expand the RFC?
• Incorporate feedback in Parametrize templates templates#7 (comment)

[roberth]

I'd like nix itself to fulfill the "run arbitrary project-specific command" role; see NixOS/nix#6241. Not a reason not to plan this for a flake-parts CLI, but doing it in Nix itself further improves standardization.
Also I can review as a Nix team member nowadays, and it's a reasonable "good first issue".

[srid]

Related: flake-parts/templates#7 (comment)

[roberth]

We don't have eval in Nix, making this slightly inefficient. Something like

withSystem system (import (builtins.toFile "something descriptive" "args: with args; ${exprStr}"))

withSystem would only apply to perSystem things, but can be "ported" to the top level. Also going through allSystems is a bit backwards if you're defining something in perSystem, so that part could be ripped out when writing the right function for this.

[roberth]

I think it should be acceptable for users to write configs in plain Module System style here.
The CLI should try not to assume that the TOML is the only input to evaluation, because that would be anti-modular and a problem for e.g. modules that auto-configure other modules. In other words there is no boundary between user definitions and modular definitions, and generally all reading of the configuration should be done through the Module System.

[srid]

I imagine the user can hand-edit (or through the cli) the modules list to include custom .nix modules. Shouldn't this the case for inputs as well? The START...END suggests, however, that the user is not supposed to hand-edit the inputs.

[srid]

Is ${...} the best we can do for referring to packages? Do we have to support arbitrary Nix expressions with variables in scope?

[srid]

In some cases, we also need conditionals, like:

      perSystem = { config, self', pkgs, lib, ... }: {
        rust-project.crane.args = {
          buildInputs = lib.optionals pkgs.stdenv.isDarwin (
            with pkgs.darwin.apple_sdk.frameworks; [
              IOKit
            ]
          );
        };
      };

How would the TOML represent this case?

[srid]

I think as a first milestone, we should create a flake-parts module that supports using any module in this TOML format (to the extent feasible). The CLI doesn't have to exist yet at this point.

Is TOML the most suitable format here? What are the advantage of using a known format over Nix attrsets? JSON has JSON schemas which is supported in VSCode for validation (with LSP errors), which provides a user-visible advantage of using JSON over Nix attrsets (you get autocompletion, etc.). With TOML, I don't see any advantage aside from ease/familiarity of the syntax.

EDIT: This seems relevant, https://docs.clan.lol/blog/2024/05/25/jsonschema-converter/

And there's lib.importJSON already:

---

EDIT 2: TOML can use JSON schemas: https://marketplace.visualstudio.com/items?itemName=tamasfe.even-better-toml#completion-and-validation-with-json-schema

[roberth]

JSON has JSON schemas

❗ https://discourse.nixos.org/t/introducing-the-nixos-to-json-schema-converter/45948

Is TOML the most suitable format here?

It does not have null, but it might not be all that common, because often it only occurs as an option default. It'd be for disabling things, but that can often also be done with an enable option.

HCL comes to mind, but at that point we might as well pick the data subset of Nix, NIXON, I guess.