[feat] modularise ghc.nix

[MangoIV]

Changes

Hi, I have spent some time modernizing and revising the nix code (hopefully) without any breaking changes but with some awesome new additions:

• the flake is now written using flake-parts. This makes it such that the configuration is clean and easy and removes ugly hacks
• I have written a flake parts that can very easily imported in a flake-parts flake, for an example usage, please refer to the modules template that I have added, as you can see it's beautifully easy, it now provides helpful error messages (by the virtue of evalModules) and it is still customizable.
• I have added a new packages output that compiles all module options, as well as the README to an mdbook that can serve as the new goto point for documentation, I have also added the necessary code to deploy this book to github pages.
• the formatting devshell is now built upon devshell which is a project by numtide that also provides a flake part and promises easy and beautiful configuration as well as less bloat

The idea is to slowly migrate ghc.nix towards module based configurations as this will make getting started much easier, especially for users who only have contact with nix through ghc.nix

The README rendered in the new mdbook

The new modules in the module docs mdbook

[MangoIV]

I think if we want to deploy the documentation, there need some actions to be taken... :3

[MangoIV]

if you want this of course @.@

[MangoIV]

because @chreekat asked about it, here is the justification for flake-parts. Currently there are two "classical" ways to deal with the system attribute, namely the adhoc defined forallSystems functions or the flake-utils way, both of them are either ugly and hacky (forallSystems) or both ugly and incorrect (flake-utils). Neither of them solves adherence with the flake output schema nor management of reusable flake parts. flake-parts solves both of these issues. It defines a new perSystem attribute, that gets passed all the arguments that you might need in an already applied (perSystem) manner. While flake-parts itself is fairly new, the underlying technology (nixos modules) is very battle tested and has turned out to be the most ergonomic and failsafe way to interact with nix. Additionally, for the user nothing has to change, there's just one additional template that allows for the use with modules, else everything stays the same. The ghc.nix flake dev profits from an easy to read flake, reusable modules (see https://flake.parts) and better error messages.

[TeofilC]

I'm just a user of ghc.nix so take this with a grain of salt.

But I am quite sceptical of integrating something like flake-parts into ghc.nix. I feel like it adds an extra layer of abstraction that isn't necessary to achieve similar levels of customization. It also requires future contributions to have an understanding of flake-parts, which many nix users won't have.

[MangoIV]

That’s kinda the point I was trying to make. Flake-utils and the foreachSystem hack require more understanding than flake-parts. flake utils I have seen used incorrectly so often in the wild, too.

[TeofilC]

Fair enough. I'm happy to accept that it makes it easier to write things like that correctly.

My worries are mostly around familiarity, stability, complexity, and tightly coupling ghc.nix to a quickly moving ecosystem.

(Also I'm not a maintainer here so don't feel like you need to convince me)

[MangoIV]

Also if you’re doubtful, look at the new flake template, it’s simple.