Modular overrides

[srid]

Resolves #101 (and resolves #82 by design)

What this PR does

Retire source-overrides and overrides in favour of a more friendly/ modular design, viz.: packages (configure both source overrides & local packages) and settings (modular replacement for overrides and use pkgs.haskell.lib). The outputs.finalOverlay value is computed from these two options. There are other associated changes; see ChangeLog.

Example: srid/emanote#437

Tasks:

• Initial implementation
• Evaluate the design, and finalize API
• Add the rest of settings.<name>.* options, mirroring pkgs.haskell.lib.
• Docs
• ...

[srid]

@roberth What do you think (re: "Evaluate the design, and finalize API" in the PR description)?

For context, here's your previous comment (I might be misunderstanding some of that): srid/emanote#437 (comment)

[srid]

Not sure why, after ed06b2d, the CI fails around doc tests:

       … while evaluating the option `perSystem.haskellProjects.<name>.projectRoot':

       error: A definition for option `perSystem.haskellProjects.<name>.projectRoot' is not of type `path'. Definition values:
       - In `/nix/store/fl5jf3qnhndz7lb50l92s5rgdyljaj7v-source/nix/modules/project.nix'

[srid]

Another example: nammayatri/nammayatri@8c640d6

[srid]

I think it is time to (squash) merge this now. But I'm still receptive to any or all feedback (regarding implementation or API). We can certainly change things before next release (0.4).

[roberth]

The option documentation at perSystem.haskellProjects..packages is incomplete, it doesn't tell me what's valid to put there. An example would be very helpful, but sub-options would be even better, if feasible.

I think part of the problem is deferredModule, which only renders documentation if you use deferredModuleWith { staticModules = ...; }, but that's only usable if you have modules should always be imported, which may not actually be the case here.

[roberth]

I would like to be able to still specify an overlay of haskell packages, because that helps me when sending changes to Nixpkgs. Judging from the list of options and the changelog, that's not an option anymore?

[srid]

Judging from the list of options and the changelog, that's not an option anymore?

Yes, but you can use basePackages = pkgs.haskellPackages.extend ....

We could add an overlays option (that cannot be merged), but is there a reason for it?

[roberth]

I just lacked the creativity to do it in basePackages.

is there a reason for it?

It's more efficient to provide all overlays in one go, to avoid computing the fairly expensive fixpoint of the otherwise unnecessary package set with this overlay, but without the built-in overlays. Or to put it simply, we should try to invoke extend only once.

Actually we could work with Nixpkgs to provide a function that behaves like pkgs.haskellPackages.extend without having to evaluate the pkgs.haskellPackages attrset first, but that's an unnecessary scope creep for now.

[srid]

Let's do this -- #273. But I trust that you can use extend until that.