Open MangoIV opened 1 year ago
@MangoIV I'm fundamentally not against this. It's a bit hard for me to judge what the impact would be. Can you help elaborate on that?
Would existing consumers still be able to use haskell.nix as it is today?
For the consumer there is two main impacts:
flake-parts
apiFor haskell.nix
, if both APIs are maintained this of course causes maintenance overhead and it would probably be good to remap the old API onto the new one such that documentation from the modules can be reused. I'm not aware of how hard this will be but I imagine it to be quite a chunk of work.
I guess we can reuse a lot because we're already passing modules to cabalProject'
and stackProject'
Sounds like a good idea to me.
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.
FWIW I have been using haskell.nix with flake.parts and I am slowly getting an idea of how they could work toghether.
Description of the proposal
flake-parts
are a new, really nice framework for defining nix flakes. They allow for easy composability, nice error messages, usage of types and easy, automated documentation.Especially the latter three is what
haskell.nix
lacks a bit, imho. I think exporting a flake part would simplify documentation and make configuration of a Haskell project withhaskell.nix
very easy.In my opinion flake-parts are the first framework that really feels somewhat "polished" and not adhoc.
haskell.nix
itself uses the module system, however, I think a more complete documentation, reuse of the tools provided byflake-parts
(this would also reduce maintenance overhead) could really increase adoption.Describe the solution you'd like
I would like
haskell.nix
to export aflakeModule
similarly to how e.g. cachix/pre-commit-hooks.nix or hercules-ci/hercules-ci-effects does it and to ultimately integrated within the documentation in https://flake.partsDescribe alternatives you've considered / Additional context
Providing wrappers is the biggest alternatives but it mainly causes duplicated work for consuming parties, it would be nice to just have the support for this upstreamed here.