-
Notifications
You must be signed in to change notification settings - Fork 848
Improve module structure for faster builds and better separation of concerns #2334
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
Comments
My PR #2328 is also a step in the general direction described here. |
👍
👍
👍 👍
There might be a cyclic dependency problem. Feel free to normalize it. Long compile times are obstacles to feeling motivation to contribute.
Your proposal here sounds like a nice way to reduce compilation too, and clear up the way commands are declared nicely.
The reason for the Show instance will have been while debugging someone probably needed it. Does removing the Show instance improve compile times significantly? I'm usually pretty miffed when I'm debugging and I can't look at the value of something. Good proposals! Keep them coming. Great work. 👍 |
I have created separate issues for most of the ideas above. For the point "Generally move types into the Stack.Types.* modules" I currently fail to find the problematic modules. I'll stay aware of this idea though, and will point those types out when I come across them. |
A few ideas:
Delete
Stack.Types
The modules would then only depend on the
Stack.Types.*
modules that they actually need and e.g.Stack.Clean
wouldn't have to be recompiled after a change inStack.Types.Nix
.Split up
Stack.Options
and move option parsers to option typesBecause
Stack.Options
has a lot of dependencies it is currently recompiled after most changes.Splitting it up would also make changes on option types more localized.
But maybe I just don't understand the original motivation for introducing that module.
Generally move types into the
Stack.Types.*
modulesParticularly types with a lot of (derived) instances take rather long to compile.
Split up
Stack.Types.Config
This module takes a really long time to compile. And why are types like
PackageIndex
not inStack.Types.PackageIndex
?The structure that I added in #1326 should probably be largely disregarded. I didn't really understand the various types at that time.
Move commands out of
Main
I think it would be really nice if all code that is specific for a command could be defined in the same module (and a separate types module ;)). E.g. I wish that in
Stack.Clean
I could define something likeIn order not to introduce a dependency on
Stack.Setup
,withEnvConfigNoLock
would only be a smart constructor for some datatype that defines actions that run in the variousStackT
environments.Delete unnecessary instances
(Included because it impacts the compile times)
E.g. why does
ConfigMonoid
need aShow
instance?Thoughts?
Do these ideas maybe run counter to other goals for
stack
?The text was updated successfully, but these errors were encountered: