Skip to content

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

Closed
sjakobi opened this issue Jul 5, 2016 · 3 comments
Closed

Comments

@sjakobi
Copy link
Member

sjakobi commented Jul 5, 2016

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 in Stack.Types.Nix.

Split up Stack.Options and move option parsers to option types

Because 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.* modules

Particularly 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 in Stack.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 like

cleanCommand :: Command CleanOpts
cleanCommand = Command
    { commandName = "clean"
    , commandDescription = "Delete build artifacts in the current project"
    , commandAction = withEnvConfigNoLock (\globalOpts cleanOpts -> clean cleanOpts)
    , commandOptsParser = cleanOptsParser
    , commandAvailableInInterpreterMode = False
    }

In 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 various StackT environments.

Delete unnecessary instances

(Included because it impacts the compile times)
E.g. why does ConfigMonoid need a Show instance?

Thoughts?

Do these ideas maybe run counter to other goals for stack?

@sjakobi
Copy link
Member Author

sjakobi commented Jul 6, 2016

My PR #2328 is also a step in the general direction described here.

@chrisdone
Copy link
Member

chrisdone commented Jul 20, 2016

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 in Stack.Types.Nix.

👍

Split up Stack.Options and move option parsers to option types

👍

Generally move types into the Stack.Types.* modules

👍 👍

This module takes a really long time to compile. And why are types like PackageIndex not in Stack.Types.PackageIndex?

There might be a cyclic dependency problem. Feel free to normalize it. Long compile times are obstacles to feeling motivation to contribute.

Move commands out of Main

Your proposal here sounds like a nice way to reduce compilation too, and clear up the way commands are declared nicely.

Delete unnecessary instances

(Included because it impacts the compile times)
E.g. why does ConfigMonoid need a Show instance?

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. 👍

@sjakobi
Copy link
Member Author

sjakobi commented Jul 24, 2016

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.

@sjakobi sjakobi closed this as completed Jul 24, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants