I'm not convinced flake inputs should exist

Development Nix
30

infuse

@amjoseph Looks interesting! I’ve been using a similar construct, using functions as the delimiter for traversal:

using pkgs {
    xrdp = { xrdp }: xrdp.override {pulseaudioSupport = true;};
    my-hello = {hello}: hello:
    pkg-from-file = ./default.nix;
    pkgA-from-dir = ./a;
    acmePackages = ./pkgs;
    my-other-hello = {hello}: hello.overrideAttrs {name = "my-name";};
    my-cmd = {runCommand}: runCommand "mine" {} "touch $out";
    python3Packages.thing = {requests}: requests.overrideAttrs {name = "my-requests";};
    lib.add1 = {}: a: a + 1;
    data.b = {lib}: lib.add1 12;
    _hiddenDep = {stdenv, lib}: stdenv.mkDerivation ....;
}

This allows for a simple lib.recursiveUpdate for merging. So I can imagine incorporating infuse as well, to simplify the cases of override/overrideAttrs. In my implementation i started adding some nice features with an “expand” step that would interpret some things to add niceties ( a = {}; roughly means a = {a}: a;, or handling path directories. Your lib is adding another set of handlers specialized to overrideAttrs and override (plus with better names!). I do like your idea of interpreting lists as pipes, so far I’ve only been map’ing through them. Mind if I incorporate some of those ideas/conventions into my lib?

random ideas

Two more random ideas to bounce around:

  1. Make use of the otherwise useless <thing> syntax in flakes to access/define inputs instead of NIX_PATH. Sure, it’s an easy way to do the wrong thing, but easy to syntactically detect without eval, build tooling can manage them, less weaving of self or inputs everywhere. You can get the same behavior as Go, where importing a new module anywhere is detected and becomes part of the root, tracked and locked.

  2. Subflakes don’t quite work the way people expect, but peolple keep trying to use them to fill a need. Introduce a new concept “crystals” (just a tiny snowflake!). It’s definition looks like another flake, but it can never have its own lockfile. Instead its inputs declarations bubble-up the to host flake’s lock, and all the input values flow back to the crystal during eval. This is similar to the Cargo.toml and workspaces concept. Allows to group and subdivide input definitions (PoC: init: crystal support · flox/nix@8a684bd · GitHub).

Flakes also provide standardization and a URL scheme to give things names. Inputs are also needed in some form, but i agree they should be improved.

callPackage and overlays

IMO this is because makeScopeXXXXXX and callPackage functions aren’t powerful enough:

@SergeK Can you clarify? I’ve been digging into these two and making variants that are aware of hierarchical attrsets / package sets. Or do you mean something else?

3 Likes