Multi-package projects #27
Conversation
HariAmoor-professional
force-pushed
the
issue-7
branch
6 times, most recently
from
83bdefa
to
2a59a7b
Compare
HariAmoor-professional
force-pushed
the
issue-7
branch
from
2a59a7b
to
4a39868
Compare
| topLevelPackages = mkOption { | ||
| type = types.submodule { | ||
| options = { | ||
| enableMultiPkgs = mkBoolOption { |
There was a problem hiding this comment.
Could this be inferred from dirs != []?
| devShell = with pkgs.haskell.lib; | ||
| (addBuildTools package buildTools).envFunc { withHoogle = true; }; | ||
| (addBuildTools package buildTools).envFunc ( |
There was a problem hiding this comment.
Perhaps instead of envFunc, hp.shellFor would be nicer, because it merges the environments of multiple packages.
| if cfg.topLevelPackages.enableMultiPkgs then | ||
| hp.${cfg.topLevelPackages.defaultPkg} | ||
| else | ||
| cfg.modifier (hp.callCabal2nixWithOptions cfg.name cfg.root "" { }); |
There was a problem hiding this comment.
I think it's desirable to use the overlay (haskellPackages.extend) even in case of a single package, because it removes the possibility of accidentally using the Nixpkgs version of the package instead of the locally defined one.
| @@ -110,6 +110,32 @@ in | |||
| }; | |||
| }; | |||
| }; | |||
| topLevelPackages = mkOption { | |||
There was a problem hiding this comment.
I think the topLevelPackages namespace shouldn't be necessary.
There was a problem hiding this comment.
@roberth Then how do you define defaultPkg? Or should you not need to?
There was a problem hiding this comment.
We should not need to define a single package.
Currently haskellProjects.<proj> defined a flake packages package for each <proj>. That 1:1 relation is what package is for, but now we'll have multiple packages per project.
For each haskellProjects.<proj>.dirs.*, we could have a package named <proj>-<dirname>.
Ideally we'd use the actual package name instead of the directory name.
A list of directories is actual a bit "high level". I think a good first step is to create an attrsOf submodule for the locally defined packages. For example:
haskellProjects.<proj>.package.<pkgname>.src
haskellProjects.<proj>.package.<pkgname>.packageAttribute (default: ${proj}-${pkgname})
The logic for that should be more straightforward to implement than dirs, but you can still write dirs to make use of those options and get a good separation of concerns. It also allows a bit more control: customizing the package attribute, and perhaps some extra options to pass to cabal2nix.
There was a problem hiding this comment.
Yes, the structure should be more or less like that. I just put a concrete proposal here (should have done it long ago to assist in this PR): #7 (comment)
The flakeAttribute part (or packageAttribute in the above comment) is still not clear to me. I suppose we can finalize that once the general functionality is in place (in the PR).
Change `buildInputs` to `nativeBuildInputs` Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
HariAmoor-professional
force-pushed
the
issue-7
branch
from
e51aa55
to
321dbe0
Compare
|
Closed in favor of a new PR (to be delivered) |
Closes #7
Labeled as draft b/c not yet tested