Re: Add a Nix flake

On Tue Aug 25, 2026 at 9:50 AM UTC, Greg Burd wrote:
> 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?

I think it is probably best not to muddy up the thread. I can announce
the thing when it is ready to share publicly, probably after PGConf.EU.
I think it could be a game changer for allocating and maintaining
buildfarm clients. Eventually it might help bolster your effort in this
thread.

>>> 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!

More just throwing ideas into the ether of what this could enable.
Definitely not recommending it for a v1, but given the discussion in the
other subthread, maybe showing an example of what we could do in a NixOS
VM test that we currently don't do in our current setup could be
appealing to show people a benefit.

>> 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.

For what it's worth, the docs targets on Meson, at least, are not built
by default, so adding enabling the docs feature by default seems fine to
me. Then it would just be ccache left in the devShell.

> Thanks again for the careful read.

--
Tristan Partin
PostgreSQL Contributors Team
AWS (https://aws.amazon.com)