Add haskellProjects.foo.finalPackages to expose the final package set

[srid]

We want to expose the following as an option:

haskell-flake/flake-module.nix

Line 188 in 54334cf

finalPackages = cfg.haskellPackages.extend finalOverlay;

This will be useful here: https://github.com/srid/ema-template/pull/45/files#diff-206b9ce276ab5971a2489d75eb1b12999d4bf3843b7988cbe8d687cfde61dea0L63

Where instead of using lib.getExe pkgs.haskellPackages.ghcid (incorrect, because ghcid was overriden) I can instead accurately use lib.getExe config.haskellPackages.main.finalPackages.ghcid.

[roberth]

perSystem.haskellProjects.<name>.haskellPackages would have been a nice name, but that's taken.

How about haskellProject.<name>.finalPackages?

You'll have to move the overlay logic from the perSystem level to the haskellProjects.<name> level to make that work, but I think that's a nice place for that logic to be anyway.

[srid]

Sure, finalPackages is better.

But, I'm questioning the naming of haskellPackages now. Should we rename it to something else, like basePackages? The idea being:

basePackages --[ source-overrides; overrides; local packages ]--> finalPackages

It is straightforward to explain, viz.: "You start from base packages, apply overrides and local packages, you get final package set".

[roberth]

Sounds good to me!

[srid]

How about this API, where we group overlay-affecting settings into a submodule called packageSet?

haskellProjects.foo = {
  devShell.enable = false;
  packageSet = {
    # The overlays are composed in the order they are shown here.
    base = pkgs.haskell.packages.ghc944;
    local = {
      mypkg.root = ./.;  # Assumes mypkg.cabal
    };
    source-overrides = { .. }; # Overrides by direct path to source
    overrides = self: super:  { .. };  # Raw Haskell overlay
  };

Users can then use config.haskellPackages.foo.packageSet.final to access all the packages. The idea is that we can say "start from base", then we apply local, then source-overrides and finally overrides, before creating the project specific haskell package set.

Does it make sense, from API documentation/comprehension/simplicity standpoint, to group the overlay related options like this? Or is it complex? I have a tendency introduce unnecessary abstractions, so it would be good to get some feedback here.

[maralorn]

Honestly: I think most interfaces are fine if they are well documented.

From the face of it, I don’t see anything wrong with this one, but problems may only become apparent when using it. Grouping all related options under packageSet will probably be a bit complicated for very simple flakes, but I don’t have a strong opinion about it. Besides packageSet.final I’d like to see a read-only option like packageSet.localPackages or something where one can get all local Haskell packages (to e.g. iterate over) but does not include other packages which could also be in the default packages attribute.

[srid]

I’d like to see a read-only option like packageSet.localPackages or something where one can get all local Haskell packages (to e.g. iterate over) but does not include other packages which could also be in the default packages attribute.

@maralorn With #63 you can access the local packages in the "foo" project using config.haskellProjects.foo.outputs.packages.

[srid]

Done by #68; rest of discussion to continue in #72