-
Notifications
You must be signed in to change notification settings - Fork 247
Refactor and simplify parts of overlays/haskell.nix #1976
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor and simplify parts of overlays/haskell.nix #1976
Conversation
overlays/haskell.nix
Outdated
}; | ||
inherit (config.result-of-f) hsPkgs; | ||
}) | ||
# FIXME: should this be part of cabal-project.nix? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That would be nice
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We did move most of the code for hackage-project
into a module file and I think it is nicer like that.
This might be something for another PR, but I have often wondered if we should be doing the |
Yes, I also thought about renaming the |
Just be careful around backwards compatibility and breaking changes. Haskell.nix is actively used. Existing users would need to be carefully guided to the new syntax. |
@angerman 👍 after I clean this up, there should no change to how cabalProjct and stackProject are called. I think evalProjectModules is exposed so maybe we can keep that around. |
852663d
to
43de0d0
Compare
43de0d0
to
8a39583
Compare
I am still interested in making this change, there are two things left in progress:
|
8a39583
to
a46dd90
Compare
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
@andreabedini did anything ever happen here? Should we keep this open? |
Nothing happened after #1999. I still have my branch so maybe it's ok to leave it closed... until next time? 😂 |
I am opening this for visibility and to track my work. As it stands this PR is riddled with unnecessary changes and might not be worth reviewing in the current state.
The core parts of haskell.nix are based on NixOS module system, which powers haskell.nix's flexible and customisable behaviour. I have noticed that the configurtion coming from this module layer is then "post-processed" in a seemingly ad-hoc way, rather than being done as a module as well.
An instance of this is
cabalProject'
andstackProject'
. Taking the first as an example, the current flow is:Basically
f
is passed theconfig
obtained from evaluating the modules (after injecting the user'sprojectModule
and../modules/cabal-project.nix
). Soargs
inf
is just the moduleconfig
. This calls forf
to be a module in itself. We can inlineevalProjectModule
intocabalProject'
and turnf
into a module that adds something to the config:As far as I can tell, this transformation is entirely syntactic and should preseve the semantic of the original code. We can also avoid setting
_module.args
sincef-now-turned-module
can export it directly (with minimal changes to the other modules). A step further would movingf-now-turned-module
into../modules/cabal-project.nix
given it is a necessary part of configuring a cabal project.A similar transformation can be done for
stackProject'
.Furthermore, if I understand correctly, there are two different invocations of
pkgs.lib.evalModules
corresponding to the configuration of very different things (the project and the package-set). I am considering separating the configuration of projects and package-sets into two separate directories, to make the distinction clear.Special thanks to @Radvendii who helped me reason about this change.