Add flake file

[jkarni]

Issue reference: #93

Submission Checklist:

• [x] Have you followed the guidelines in our Contributing document (for example, is your tree a clean merge)?
• [x] Have you checked to ensure there aren't other open Pull Requests for the same update/change?
• [x] Does your submission build?
• [x] Does your submission pass tests?
• [x] Have you run lints on your code locally prior to submission?
• [x] Have you updated all of the cabal/nix infrastructure?
• [x] Is this a breaking change? Have you discussed this?

[kvanbere]

I don’t know enough about nix to know whether this is okay or not, but one thing that stands out to me is the flake description - maybe it should be changed from the default.

Happy to merge it.

[kvanbere]

@ashercuedo

[ashercuedo]

Thanks for the pull request, I'll get onto it as soon as I can 👍

[jkarni]

one thing that stands out to me is the flake description - maybe it should be changed from the default.

Good call - changed to something more specific.

[ashercuedo]

Looking pretty good I reckon. Just curious, I'm not super familiar with .Nix - but is there a reason why the file uses nixpkgs from the unstable branch?

nixpkgs.url = "github:nixos/nixpkgs?ref=nixos-unstable";

Totally cool if that is a common thing to do, just thinking that since this is supposed to be a generic Flake file we might want to change it to the same as the Nix wiki:

nixpkgs.url = "github:NixOS/nixpkgs";

[kvanbere]

@jkarni

[kvanbere]

@roberth would it be possible for you to give us a hand here

[roberth]

I would normally use haskell-flake, which provides a bit more tooling by default, and higher level options.

[roberth]

I've opened https://github.com/cuedo/github-webhooks/pull/97 to show the alternative. I don't think anything's particularly wrong with this PR, but if you pick this one, presumably you're looking for more minimalism, and you could get rid of flake-utils and use the Nixpkgs library directly. I don't particularly care for that kind of thing, because this is an "end user" kind of flake anyway; it's not like we have a scalability problem here, so ease of use should come first.