build: add flake.nix

[teto]

run nix develop to get a development environment

[maralorn]

Thanks @teto. Sadly a majority of maintainers of this project thinks that flakes is an experimental feature and endorsing its use is a footgun for beginners. Imo we can keep this PR open until there is a stable release of nix which supports flakes without experimental flags.
otoh a flake.nix wouldn‘t hurt anyone so I wouldn‘t veto anyone else from merging it.

[maralorn]

On further inspection: @teto where did you get the flake template from? It seems riddled with design decisions that seem very opinionated and overcomplicated. Templates like these are a reason why nix beginners get overwhelmed.

[teto]

Right now there is neither a shell.nix or a flake.nix which is strange for a nix project. I've added a shell.nix via the flake-compat layer.
I've followed no template only my own foly (hls has a nice one with multiple ghc version support https://github.com/haskell/haskell-language-server/blob/master/flake.nix). What would you do differently ? 2 things I found worthwhile you may disagree with:
1/ add haskell-language-server : I just can't imagine writing haskell without it
2/ support several ghc version which makes things more complex. For now I've just put 8.10.7 but should be trivial to add 9.2 (at least from a nix perspective)

Could you be more precise about what you would do differently ?

[sternenseemann]

I see two problems with this:

• The flakes' lock file needs to be continuously updated.
  • This repository is not very high velocity, so a lock file will quickly become outdated compared to upstream nixpkgs.
  • No one with commit access actively uses flakes, so it's unlikely the lock file would be updated at all.
• We only need a shell.nix basically, I specifically do not want anyone to use cabal2nix via flakes from this repository. cabal2nix in nixpkgs is updated and maintained and should be used consequently.

Experimental Nix users can still rely on nix-shell, whereas using flake-compat just adds extra wait time for all others for a simple shell.nix.

For the sake of completeness a few extra remarks below.

[sternenseemann]

I don't want a flake, if any, to expose a cabal2nix package. The supported and maintained ways to get cabal2nix are hackage and nixpkgs. If you want something closer to HEAD, use haskellPackages.cabal2nix-unstable or override it yourself.

[teto]

I like having the possibility to build in a sandbox from scratch (i.e. more powerful than what cabal does). It helps me check it really works. Could be useful in a CI too.
I can remove it if you dont like it.

[teto]

The flakes' lock file needs to be continuously updated.

I thought pinning was a desired property of nix to allow for reproducibility ? flakes make it easier than the rest (no niv or tofu, it's builtin). you can even override the version on the CLI in a standardized way via nix develop --override-input

This repository is not very high velocity, so a lock file will quickly become outdated compared to upstream nixpkgs.
No one with commit access actively uses flakes, so it's unlikely the lock file would be updated at all.

If no one is using it than not a problem if it's not up to date ? pinning is good since you guarantee it works.

cabal2nix in nixpkgs is updated and maintained and should be used consequently.

what if you want to develop on it ? You need some extras like cabal etc. That's the power of nix and its per-project shell.nix.

Experimental Nix users can still rely on nix-shell, whereas using flake-compat just adds extra wait time for all others for a simple shell.nix.

so there is no shell.nix, I provide one and doing so I delay the time before one becomes available ? Sorry I dont get the logic. Someone can update the shell.nix with a hardcoded version later.

[liesnikov]

Not to put the burden on @teto, but wanted to check in with the maintainers on the current stance.

Flakes gained a lot of maturity since December 2021, and while I don't think they are marked as stable just yet https://github.com/cargo2nix/cargo2nix doesn't seem to be having too many problems because of it. And I believe https://github.com/srid/haskell-flake also appeared since then.

Concretely, what would be needed from flakes to get included in caba2nix? Not marked as stable? Or perhaps something else?

[cdepillabout]

@liesnikov Oppositely, what is your use-case that you'd really like us to adopt a flake.nix? Are you not just getting cabal2nix from Nixpkgs?

[liesnikov]

At the moment I most definitely am getting it from nixpkgs.

My arguments would probably fall along the same lines as what @teto mentioned above with one addition that having a cabal2nix flake would allow for a more organic pinning of cabal2nix version without the need to explicitly bring a new nixpkgs intro the scope.
So far my understanding is that if I write a flake file and I want to pin cabal2nix I'd have to specify a version of nixpkgs to pull and then fetch cabal2nix out of it, as opposed to specifying the version in the input directly.

Perhaps it's worth saying that I don't really think any of this is too specific to cabal2nix and until now it's been a great help the way it is (thanks to the maintainters!).
So in the end I wouldn't go as far as saying "I really want it", but rather interested for the sake of more uniform approach.

[sternenseemann]

This is a development repository. You can obtain a well-tested and stable version of cabal2nix alongside useful tools like callCabal2nix and a well maintained Haskell package set from nixpkgs (whereas e.g. cargo2nix is not available from there at all). I don't see any value in giving people the opportunity to redo all this work downstream or shoot themselves in the foot by pinning some random master revision. Since cabal2nix is worked on alongside the nixpkgs package set, so there is little value in allowing arbitrary combination – if there is a real issue it is always best to solve it upstream (nixpkgs that is).

[cdepillabout]

@liesnikov To add to what @sternenseemann is saying, as far as I am aware, a flake.nix will allow you to pin arbitrary git repos (i.e. non-flake inputs), right?

cabal2nix flake would allow for a more organic pinning of cabal2nix version without the need to explicitly bring a new nixpkgs intro the scope

What would having a flake.nix in this repo get you that just pinning the cabal2nix repo wouldn't get you? If all you want is the cabal2nix sources, then just pinning the git repo should be sufficient. If you want a fully-working cabal2nix repo, then you'll need to get it from Nixpkgs anyway, so you might as well just pin nixpkgs. (And I'd argue that most people wouldn't be using raw cabal2nix on its own anyway, but use the wrapper functions like callCabal2nix as mentioned above.)