Re: Add a Nix flake

On Tue Aug 25, 2026 at 6:37 AM CDT, Andrew Dunstan wrote:
> Well, "growing" could cover a multitude of possibilities. It could mean
> there was one and now there are two. [...] But if you want to say that
> there is a significant number of people actually contributing here who
> use it that would be all the better for some evidence.

Fair, and I shouldn't have leaned on an unquantified "growing." Let me
separate what I can back up from what I can't.

What I can point to concretely:

- There is already an active pgsql-hackers thread, "Building with meson on
NixOS/nixpkgs," [1] where the Meson build was adjusted specifically
because of problems Nix/NixOS packagers hit. So Nix is already shaping
build-related decisions here whether or not we carry a flake.
- Wolfgang Walther maintains the PostgreSQL packaging in nixpkgs and has
posted here on exactly these issues.
- Supabase's fork use Nix extensively. [2]
- I keep a flake setup that I re-apply/use to enable predictable efficient
development cross-platform.
- Tristan (upthread) keeps a private flake and a NixOS-based buildfarm
client.

What I can't do is hand you a survey. I don't have a count of contributors
who develop on Nix, and I'd rather admit that than dress up a guess. If the
bar for this is demonstrated contributor demand, that's a reasonable bar and
I'm happy to let the thread be the evidence, if it's just me and Tristan, so
be it; this can wait.

> Historically we've been fairly resistant to carrying things related to
> how people build or develop postgres.

Understood, and I don't want to relitigate that policy. The narrower claim
I'd make is that a flake is closer to the .editorconfig / .dir-locals.el end
of the spectrum (declare-the-environment) than to endorsing a build system,
it doesn't touch configure, Meson, or the Makefiles. But I take the point
that the door being narrow is deliberate.

On Tue Aug 25, 2026 at 8:19 AM CDT, Tom Lane wrote:
> I might hold my nose if the effects extended only to one more root-level
> file (although that's not great). But if we're talking about rather
> expansive .gitexclude patterns, I'm going to push back on the grounds of
> possible unforeseen side-effects on other peoples' work.

That's a fair objection and easy to remove: v3 (attached) is exactly one new
root-level file, flake.nix, and nothing else. I've dropped the .gitignore
changes entirely.

For what it's worth on side-effects: the patterns I'd proposed were
root-anchored (/flake.lock, /result, /result-*), the same shape as the
existing /tmp_install/ and /portlock/ lines, so they couldn't have matched a
result/ elsewhere in the tree. But that's beside the point now, they're gone.

The build artifacts belong in each developer's own $GIT_DIR/info/exclude,
which is precisely what the .gitignore header already recommends for "files
from local workflows"; `nix build -o` can also just name the symlink. No
committed-ignore changes needed.

So the question really does reduce to your "one more root-level file, though
that's not great." I won't pretend that's nothing. If the consensus is that
even one file is more build/dev tooling than the tree wants to carry, I'll
accept that outcome, but if it's going to live somewhere, one self-contained
file at the root is the smallest footprint I can offer.

best.

-greg

[1] https://pg.ddx.io/m/pgsql-hackers/5d6b6485-9eff-44a0-99ac-661fdeb72a21(at)technowledgy(dot)de/T/
[2] https://github.com/supabase/postgres/blob/develop/flake.nix