You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I can't think of an easy to way to fully modularize the nix devShell, however I think we can get closer.
Unlike flake-parts mkFlake, we start with a base devShell (ie., whatever shellFor returns), and then build up the mkShellArgs values using the module system. So, instead of:
Those 3 modules (mission-control, flake-root, pre-commit) would export the associated config that will be merged. Like #82, we can't predict the order of merging, so things like shellHook could be problematic in some cases.
All of this can happen in separate repo, and haskell-flake can simply use that to evaluate the final mkShellArgs from the given module.
The text was updated successfully, but these errors were encountered:
I can't think of an easy to way to fully modularize the nix devShell, however I think we can get closer.
Unlike flake-parts
mkFlake
, we start with a base devShell (ie., whatevershellFor
returns), and then build up themkShellArgs
values using the module system. So, instead of:the user simply have to write:
Those 3 modules (mission-control, flake-root, pre-commit) would export the associated config that will be merged. Like #82, we can't predict the order of merging, so things like
shellHook
could be problematic in some cases.All of this can happen in separate repo, and
haskell-flake
can simply use that to evaluate the finalmkShellArgs
from the given module.The text was updated successfully, but these errors were encountered: