Re: Add a Nix flake - Mailing list pgsql-hackers

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