Nixtamal: Fulfilling, Pure Input Pinning for Nix

Folks, after understanding the pain points of flakes, should give classic Nix another shot (such as using a release.nix for all your builds outputs & exposing overlays to users) as you are freed of flake’s design limitations rather than trying to fight so hard against it.

I absolutely agree. I find the most flexible approach is to put the derivation boilerplate in default.nix, as a function with arguments for each "input"/"dependency", and default values for all of those args, e.g. something like:

{
  nixpkgs ? builtins.fetchTarball {
    sha256 = "1915r28xc4znrh2vf4rrjnxldw2imysz819gzhk9qlrkqanmfsxd";
    url = "https://github.com/nixos/nixpkgs/archive/11cb3517b3af6af300dd6c055aeda73c9bf52c48.tar.gz";
  },
  pkgs ? import nixpkgs { config = {}; overlays = []; },
  python3Packages ? pkgs.python3Packages,
  src ? pkgs.lib.cleanSource ./.,
}:
python3Packages.buildPythonApplication {
  inherit src;
  pname = "my-app";
  version = "1.2.3";
  propagatedBuildInputs = [ python3Packages.requests ];
}

That's enough to use nix-build, nix-shell, etc. and it's trivial to override (just call it with different arguments; they'll propagate through references too, e.g. overriding pkgs in the above will also cause python3Packages and src to be overridden).

If you want to provide overlays, flakes, shell.nix, release.nix, etc. then their boilerplate can go in separate files which load that default.nix (hint: if you use pkgs.callPackage instead of import, you'll get a .override function added automatically!).

If my default.nix file gets too unwieldy, I'll pull out the parts to separate files (usually in a nix/ subdir); and it's perfectly possible to take default values from a pinning system (I've not used nixtamal; but I have used alternatives like niv).

Many of my projects (work and personal) don't need any of that extra stuff though.

This sort of project also composes well, e.g.

{
  pkgs ? import nix/nixpkgs.nix,
  foo ? import (fetchGit { url = "http://example.com/foo.git"; rev = "abc"; }) {
    inherit pkgs python3Packages;
  },
  bar ? import (fetchGit { url = "http://example.com/bar.git"; rev = "def"; }) {
    inherit foo pkgs python3Packages;
  },
  python3Packages ? pkgs.python3Packages,
  src ? pkgs.lib.cleanSource ./.,
}:
python3Packages.buildPythonApplication {
  inherit src;
  name = "quux";
  version = "99";
  buildInputs = [ foo bar python3Packages.baz ];
} // { inherit foo bar; }

Here the quux project is loading the foo and bar projects from separate git repos, and overriding their dependencies with its own for consistency (alternatively it could leave their dependencies at their default values, which are presumably known to work, but may lead to redundancy or mismatched versions in the overall combination). We might imagine that the bar project is doing a similar thing for its foo dependency, but we don't need to care since it's easily overridable to be consistent.

As a bonus, I've added // { inherit foo bar; } so that anyone loading this project can easily get the foo and bar dependencies it was using. If bar were to expose its foo dependency in this way, we could use that as our default value (using a little indirection: foo == null will use bar's default value; foo != null will override bar's default value; we need this indirection to avoid overriding bar's default value with bar's default value, which would be an infinite loop!):

{
  pkgs ? import nix/nixpkgs.nix,
  foo ? null,
  bar ? import (fetchGit { url = "http://example.com/bar.git"; rev = "def"; }) {
    inherit pkgs python3Packages; 
    ${if foo == null then null else "foo"} = foo;
  },
  python3Packages ? pkgs.python3Packages,
  src ? pkgs.lib.cleanSource ./.,
}:
with {
  resolved.foo = if foo = null then bar.foo else foo;
};
python3Packages.buildPythonApplication {
  inherit src;
  name = "quux";
  version = "99";
  buildInputs = [ resolved.foo bar python3Packages.baz ];
} // {
  inherit bar;
  inherit (resolved) foo;
}

Though, of course, flake.nix isn’t really Nix, since it prohibits most language features.

Note that most of flake.nix supports arbitrary Nix. It is evaluated in pure mode by default, though. The inputs in particular is the limited subset.