Stack ghci build

[chrisdone]

Pinging @snoyberg to review. I don't know what the sans-tests/with-tests distinction is for with lpPackage vs lpPackageFinal. In this case the semantics of the bools changes somewhat in packageConfigEnableTests and packageConfigEnableBenchmarks because it doesn't necessarily mean an action will be performed, but it does mean stanzas of test suites and benchmarks are enabled.

With this change, it would make lpPackageFinal redundant, but I don't know what that's for. I struggled generally to read the codebase.

This passes the test suite at least and behaves as expected: http://lpaste.net/4831131355167326208

[snoyberg]

Unless I'm misreading, this will break the test-cycle case: when package B depends on package A, but package A's test suite depends on package B. That's the reason for the two different sets of dependencies: so we can build and install the library and only after that deal with the test suite.

[snoyberg]

It seems to me like some of what you're aiming for here may be achieved if we implemented #651. More generally, we may want to start thinking of individual components within a package as being much more autonomous than we think of them today.

[chrisdone]

Unless I'm misreading, this will break the test-cycle case: when package B depends on package A, but package A's test suite depends on package B. That's the reason for the two different sets of dependencies: so we can build and install the library and only after that deal with the test suite.

I see, then this approach can't work.

It seems to me like some of what you're aiming for here may be achieved if we implemented #651. More generally, we may want to start thinking of individual components within a package as being much more autonomous than we think of them today.

Right, if #651 were implemented then this would be doable more directly (enabling both test and benchmark for build, but skipping the final action step). All I'm after here is to make sure that the test suite and benchmark's dependencies are available before starting GHCi.

In parallel I have an issue to enable specific stanzas when launching stack ghci (#727), which would allow to just load up the library and executable.

If #651 is a big upheaval to do right now, a possible alternative implementation for this task could be that, seeing as I already know all the packages that I want to specify as -package x -package y -package z to GHCi, then I could run a separate build for those dependencies as if I'd run stack install x y z. So in this case it'd be stack install temporary hspec etc. As opposed to this PR approach which is trying to let stack build figure out that it needs to install those deps. The final alternative is to just flag up to the user, "these packages aren't installed, you may want to run stack install x y z", but doing this automatically seems more in line with stack's goals of doing the right thing by default.

(All these points share the same code with stack ide, so it applies there too.)