Re: Add a Nix flake

On Mon Aug 24, 2026 at 2:39 PM CDT, Tristan Partin wrote:
> +1

Thanks Tristan, glad to have another Nix user weigh in.

>> A single blessed flake in the tree gives everyone the same reproducible
>> starting point [...]
>
> I am one of the people that has a private copy. I've also been working
> on a NixOS-based buildfarm client that includes a derivation for the
> buildfarm-client code.

That's cool, let's make sure this and that somehow knit up into something
useful. Do you want to share it on this thread or start another one?

>> One deliberate omission: there is no flake.lock.
>
> I think the lack of flake.lock makes sense. I would add it to the
> .gitignore. Additionally, I would also add `/result` and `/result-*` to
> the .gitignore.

Done. Added a small "Nix (see flake.nix)" block to the root .gitignore
covering /flake.lock, /result, and /result-*. Root-anchored so we don't
accidentally ignore a result/ somewhere in the tree.

>> To use it you'll need to be in a Nix environment. This means a Nix-based
>> OS like NixOS or the macOS/Windows layers [...]
>
> Can be Linux as well! For instance, I am using Nix on Fedora, which is
> available in the Fedora system repositories.

Good correction, you're right, and it's an important one. Nix runs anywhere
the package manager is installed; it doesn't require NixOS. I'll fix that
wording in the commit-message/docs framing rather than the code, since the
flake itself is already OS-agnostic and useful in all these locations. As
it happens I use Nix on Fedora on one host, Nix on BSD on another, NixOS
on a separate host and I'm also working to Nix-ify Illumos [1].

>> Flip any single feature (26 toggles) without a preset:
>> nix build --expr '(builtins.getFlake (toString ./.)).packages...'
>
> I didn't know that this was a thing. What a mouthful!

Agreed, it is. It's the escape hatch, not the ergonomic path, most people
will want a preset or their own thin wrapper flake with `.override { ... }`.
I included it only to show the full toggle surface is reachable without
editing the file.

I'm also sure there are ways to add simplified common config into the flake
but I was starting off with something very bland/effective and hopefully
not overly opinionated to gain buy-in.

> I think this will also have side benefits of making things easier to
> test. For instance, we could start inlining buildfarm client members
> configurations as derivations in this repository. [...] Additionally, I
> wonder if NixOS VM tests could expose new ways to do automated testing of
> Postgres.

Both are appealing, and I think they're the real long-term payoff, a
derivation library of animal configs under version control, and NixOS VM
tests for things that are painful to exercise otherwise (replication
topologies, systemd integration, upgrade paths). I'd like to keep v1 to just
the flake so it's easy to review and agree on, then build those out as
separate patches on top. Happy to collaborate!

> Regarding the code, can you explain the reasoning for the packages list
> in the development shell? It seems like everything in the list is
> already included by the Postgres package.

You're right, and thank you, that list was mostly redundant. `inputsFrom =
[ postgresql ]` already pulls in the package's nativeBuildInputs and
buildInputs, so meson, ninja, bison, flex, perl, python3, tcl, and libxslt
were all being listed twice. I've trimmed the devShell down to only what the
package does *not* provide:

- ccache (a dev convenience, not a build input), and
- docbook_xml_dtd_45 + docbook-xsl-nons (the DocBook toolchain, since docs
are off in the default package build, so `nix develop` can build docs
without a separate override).

Verified the trimmed shell still exposes meson/ninja/perl/python3/tcl/libxslt
via inputsFrom, so nothing was actually lost. Will include that in v2.

Thanks again for the careful read.

best.

-greg