Stylistic Nix expression refactoring

[jkachmar]

This is very much a subjective/stylistic PR, so feel free to request significant changes or even close it entirely if you feel that it oversteps your intentions for this repo.

---

I saw this posted on r/haskell and figured that since it’s a template, it might end up in front of people who aren’t necessarily super familiar with Nix.

To that end, I’ve refactored the default.nix expression to lay things out in a way that I think might make it easier for others to grow and extend parts of the expression gracefully.

In particular, I’ve added:

• a few more intermediate variables to help outline the process of sourcing and transforming the package set
• a utility for combining package set overlays so that it’s easy to separate things out into logical groups
• patterns that can be extended to factor these extensions out into separate files if they grow large enough

[serras]

First of all, thanks for taking the time to make the Nix code better :)

However, I don't know what to do with the PR. I understand that the code is much better, but on the other hand it's much longer, and I don't think that having more intermediate variables adds to much to the understanding.

Do you think it could be possible for you to have a PR in which this is written as an alternate.nix file which I could suggest to use when you want to extend or change more things of the Nix process?

[jkachmar]

I'd prefer not to put this in an alternate.nix file, and instead work towards something that you feel is more appropriate for the this template if at all possible.

---

I've gone through and shortened the changeset a bit, removing some of the intermediate variables and collapsing the separate overlays down into a single set of overrides.

Additionally, I introduced haskellPackages.developPackage as an alternative to callCabal2nix for the local project; this makes it so that users can simply call nix-shell at the project root and it will drop them into a sandbox (as opposed to requiring nix-shell -A env).

---

At the very least, even if the rest of these changes don't make it in, I think the original Nix expression should be updated to avoid mixing mixing override with extend. This is known to cause problems, and the recommended workaround typically involves one of the two changes I've proposed.

[jkachmar]

cf. https://nix.dev/anti-patterns/language.html#with-attrset-expression as the reason for why I'm avoiding the more concise with syntax that's used in the original default.nix.

[serras]

@jkachmar thanks for going the extra step. I think that know the file looks much better, and I honestly I wasn't even aware that I was using an anti-pattern.