Feedback-ID: idd01497b:Fastmail
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Wed, 26 Aug 2026 19:36:10 +0000
Message-Id: <DKZ4MKGOMW3K.2QJDMKLG4D188@partin.io>
Cc: "PostgreSQL Hackers" <pgsql-hackers@lists.postgresql.org>
Subject: Re: Add a Nix flake
To: "Greg Burd" <greg@burd.me>
From: "Tristan Partin" <tristan@partin.io>
References: <a0979d2a-4670-44fe-864f-c0425edbd4f1@app.fastmail.com>
 <DKXFG9FESN40.2MWLWAOUWE3YW@partin.io>
 <7ee22a5d-3776-49d5-8309-98097ffb88b1@app.fastmail.com>
In-Reply-To: <7ee22a5d-3776-49d5-8309-98097ffb88b1@app.fastmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/DKZ4MKGOMW3K.2QJDMKLG4D188%40partin.io>
Precedence: bulk

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=20
the thing when it is ready to share publicly, probably after PGConf.EU.=20
I think it could be a game changer for allocating and maintaining=20
buildfarm clients. Eventually it might help bolster your effort in this=20
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-base=
d
>>> 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 anywhe=
re
> 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 th=
e
> flake itself is already OS-agnostic and useful in all these locations.  A=
s
> 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 fla=
ke
> 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 o=
f
>> 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 j=
ust
> 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.=20
Definitely not recommending it for a v1, but given the discussion in the=20
other subthread, maybe showing an example of what we could do in a NixOS=20
VM test that we currently don't do in our current setup could be=20
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 =
=3D
> [ postgresql ]` already pulls in the package's nativeBuildInputs and
> buildInputs, so meson, ninja, bison, flex, perl, python3, tcl, and libxsl=
t
> 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 d=
ocs
>     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/lib=
xslt
> 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=20
by default, so adding enabling the docs feature by default seems fine to=20
me. Then it would just be ccache left in the devShell.

> Thanks again for the careful read.

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