Feature request: declarative sources in npins.toml

[WeetHet]

I propose an alternative API to the current one, where user would be able to declare the sources not just by running npins commands, but also in a file, say npins.toml. This would allow for a faster access to the list of sources, without revisions and a simpler API

[andir]

Can you provide an example how that would look like for our current structure? This isn't just JSON to TOML as the JSON is currently treated as machine-only and thus some optional fields are nullable, some fields only exist in certain situations. We rely on what serde is doing. Not sure we want to document that exact format for users and/or maintain two. Happy to be convinced otherwise.

[WeetHet]

Can you provide an example how that would look like for our current structure? This isn't just JSON to TOML as the JSON is currently treated as machine-only and thus some optional fields are nullable, some fields only exist in certain situations. We rely on what serde is doing. Not sure we want to document that exact format for users and/or maintain two. Happy to be convinced otherwise.

I thought about it a bit, and I think kdl feels like a better choice:

version 3
pins {
    nixfmt {
        type "GitHub"
        owner "piegamesde"
        repo "nixfmt"
        branch "rfc101-style"
    }
    
    nixpkgs {
        type "GitHub"
        owner "nixos"
        repo "nixpkgs"
        branch "nixpkgs-unstable"
    }
    
    "pre-commit-hooks.nix" {
        type "GitHub"
        owner "cachix"
        repo "pre-commit-hooks.nix"
        branch "master"
    }
}

[piegamesde]

To me the important UX question is which information should be "declarative" in the "humans" file, and which should be generated in the "lock" file.

Dependency pinning actually is a three-step data flow process, not two-step. Step 1 declare the dependency, step 2 specify version information, step 3 pin version and download information.

Tools like Cargo can paper over this fact by putting step one and two information into one "declarative" file and step three into the "lock" file. This mostly works when the majority of dependencies properly sticks to SemVer. But even then, the abstraction is leaky and stuff like cargo upgrade will automatically edit the Cargo.toml.

Because the Nix ecosystem has basically no versioning whatsoever, the three-step nature becomes a lot more pronounced. Npins is internally very aware of that, even if it ends up putting all data into the same JSON file in the end.

In order to properly provide some declarative component to Npins dependency pinning, one needs to first figure out a proper abstraction as to which information to put where and how it interacts with the CLI.