Take better advantage of cabal nix-style builds

[cdsmith]

If I figured out a few issues, I could switch to cabal's nix-style builds, and it would have a few advantages. The basic idea is:

1. Specify the environment (e.g., available packages) where client code should run, hopefully in a cabal project file?
2. Let cabal v2-install write a GHC environment file on build that describes the exact set of build artifacts that implement that environment. Pass this environment file to GHCJS when building client code.

The more formal specification of the environment (instead of "whatever packages happen to be installed right now") is its own reward. But I also expect this to make builds much faster and more reproducible. Currently, I have a tendency to sometimes hand-pick only some packages to rebuild, to save time in the development cycle, and cabal v2-install should make that obsolete.

Challenge: cabal v2-install really doesn't seem to like packages just sitting in a subdirectory. It wants them to come from some repository. I'll have to workaround this somehow.

[blackgnezdo]

I'm probably misunderstanding something, but superficially using cabal.project file should allow picking up a local version of a package without having it be published in any way.

[cdsmith]

That sounds approximately right, but I suspect there are some subtleties in getting it to work. I think this works for building the server. I still don't know how one gets from having a cabal.project file to building a GHC environment file that can be passed to GHCJS to build submitted code with GHCJS. I really don't want to have to create a cabal fail every time I build student code (though, with the current setup, I suppose that's not so hard, since student code is built in a temporary directory anyway)

[peterbecich]

work-in-progress #1523

[cdsmith]

I think there's some confusion here. By "cabal nix-style builds" we just mean cabal v2-* rather than cabal v1-*. There's no actual nix involved in this issue.