Re: Add a Nix flake

Greg Burd:
> A flake is a small, declarative
> manifest that tells Nix how to fetch our build dependencies and drop a
> developer into a shell where ./configure && make or meson setup just
> works, with bison, flex, perl, the optional libraries, and the docs
> toolchain all present and pinned to compatible versions. nix develop gives
> you that shell; nix build produces a server.

From the perspective of a Nixpkgs maintainer of PostgreSQL, having a
flake.nix in the repo does not make a difference for me. It does not
make it easier (or harder) to build PostgreSQL with it for me.

IMHO, the real value is in providing a developer shell - and you don't
need to be an everyday Nix user to benefit from it. Far from it, in fact
- you could install Nix *just* for the purpose of entering developer
shells for PostgreSQL development and not bother with it otherwise.
That's how I used Nix for years for PostgREST development initially.

I see roughly three target audiences for this:

1) Developers running NixOS. You essentially *need* a development shell
on that OS, because nothing is available globally by default.

2) New contributors, who don't want to go through setting up a
development environment from scratch for their first patch or review.
Starting a nix development shell is one command away - and no traces
left on the system afterwards.

3) Existing contributors, who need to deal with *different* sets of
dependencies. For example, I remember discussions around which minimal
versions of dependencies PostgreSQL should / will support - but how are
you going to test this as a contributor without installing either older
OS versions or keep a lot of versions for different dependencies around?

A nix flake would allow you to provide *multiple* different development
shells. One of them could be pinned to older dependencies, allowing you
to test all the minimally supported versions at once. Another one could
use the very latest dependencies of each - independent from what is
installed on the OS at the time.

> One deliberate omission: there is no flake.lock. A lock file pins the exact
> nixpkgs revision, which is the right call for an application that wants a
> frozen environment, but wrong for us. We don't want to freeze contributors to
> one snapshot of the dependency universe, and we don't want a lock file to
> become one more thing that goes stale in the tree and needs bumping. Leaving
> it out means the flake tracks whatever nixpkgs the developer already runs,
> which is exactly the behavior a build-from-source developer wants. Anyone who
> needs reproducibility can generate a lock locally; the tree stays clean.

I can see why you wouldn't want to update the lock file all the time -
but I'm afraid "the flake tracks whatever nixpkgs the developer already
runs" is not correct. Instead what happens when you run commands in this
case:

a) Nix will create a new .lock file for you, unless you pass
--no-write-lock-file.

b) No matter whether the new lock file is written or not, Nix will still
resolve the inputs the same way, i.e. taking the latest commit on
whichever channel / branch you specified in your inputs, when there is
no .lock file, yet.

In a way, this is worse: By default Nix will write a .lock file for you,
but once you .gitignore it, it won't be tracked and will be mostly
invisible. After a while the .lock file will be heavily outdated, but
you won't be aware of it.

And of course, it will break eventually, because the flake.nix file is
still written with certain assumptions, for example package names.

I'm not using flakes myself too much, so maybe I'm missing something,
though.
> Feedback welcome.
I'd suggest to approach this differently: Develop the flake in a
separate repository. Provide multiple different development shells to
choose from. Maybe a "quick start" one, one for latest deps, one for
oldest deps, possibly a shell that sets up various other tooling that is
helpful for development.

Then provide a nice readme in that repo, which allows non-Nix-users to
quickly set up Nix and use those development shells without needing to
dive into Nix itself.

The separate repo can carry a .lock file and update it regularly. It can
also move much faster initially. You can easily use these development
shells even on back branches.

Once this turns out helpful for other, previously non-Nix-using
contributors, re-evaluate whether it'd be useful to add to the main
repository.

Best,

Wolfgang