Re: Add a Nix flake

On Tue Aug 26, 2026 at 12:45 AM CDT, Tom Lane wrote:
> I don't want to block this if there's actually a reasonable amount
> of demand. Let's wait a bit to see if other requestors show up.

That's fair and I'm happy to let it sit. I won't campaign for it, if the
demand isn't there, it isn't there, and I'd rather this land because people
actually want it than because I pushed hard. I'll leave the thread open for
others to chime in.

In the meantime I've addressed the concrete points so a v4 is ready to go if
and when it's wanted. Attached.

> If we do go forward, I think the flake.nix file needs a header comment
> covering at least these points:
> 1. An explanation of what it is/does, aimed at people who never heard
> of Nix. Doesn't need to be long.
> 2. A suggestion to add thus-and-such personal ~/.gitexclude patterns
> if you want to use Nix.

Done, both. The file now opens with a short header that explains what Nix and
a flake are for someone who's never encountered them, states plainly that you
do not need Nix to build PostgreSQL (the normal instructions are unchanged
and nothing in the build depends on this file), and gives the exact
local-ignore incantation:

printf '/flake.lock\n/result\n/result-*\n' >> "$(git rev-parse --git-dir)/info/exclude"

i.e. into the developer's own $GIT_DIR/info/exclude, not the committed
.gitignore.

On Tue Aug 26, 2026 at 3:51 AM CDT, Daniel Gustafsson wrote:
> I would add a third: A note on how the file is intended to be kept up to
> date for non-Nix users. If I add a dependency to autoconf/meson, what am
> I expected to do to make sure this file doesn't become stale.

Good question, and it's the one that actually matters for whether this is a
burden on people who don't use Nix. The honest answer, which is now in the
header:

You are not expected to do anything. If you add a new optional dependency to
configure/meson and don't touch this file, the flake keeps building, it just
won't expose the new feature. The Meson path sets mesonAutoFeatures =
"disabled", so nothing gets silently auto-enabled or auto-broken by an
unknown dependency; the feature is simply off until someone adds a toggle.
Adding one is a two-line change (a boolean plus its buildInput and flag), and
such patches are welcome on -hackers, but the tree never breaks in the
meantime because no part of the normal build consults this file.

So the maintenance contract is deliberately weak by design: a non-Nix hacker
can ignore it entirely, and the worst outcome of it going stale is a missing
feature toggle, not a broken build.

Taking the wiki suggestion directly: I've drafted a companion page (attached,
Nix_Flake.mediawiki, not yet published) with the longer-form version, what
Nix is for someone who's never used it, a quick start, the local-ignore
recipe, the presets, and a full option reference alongside the same "keeping
it in sync" notes. If there's interest I'd post that to the wiki and keep the
in-file header short; if not, no harm done, the header stands on its own.

Happy to sit on this until the demand question resolves.

best.

-greg