Story for new-build tests into the global store

[ezyang]

At the moment, none of the new-build tests exercise the codepaths that install into the global store (.cabal/store) in any meaningful way. This is bad (for example, #4015 can only be triggered by a package being installed into the global store), but it is a bit difficult to fix for a few reasons:

1. Ideally, the cabal-install tests should be runnable offline, without needing to hit Hackage to download things
2. The .cabal/store is a big giant shared resource; we would need to ensure that we don't actually install into it to keep tests independent of each other
3. Minimal test-cases involve synthetic packages, but we don't want to be in the business of uploading dummy packages to Hackage just to test.

So it would seem that the only reasonable thing to do is to make sure we have some way of maintaining a separate local Hackage instance, which we can point cabal-install at, and make sure we have independent stores for each test. Probably needs a bit of jiggery pokery.

Maybe this will be easier to do when #3667 is fixed.

[dcoutts]

If we support local tarball packages then we can also exercise the store code paths.

[ezyang]

Yeah but I don't want to check in tarballs to the repo ;)

[phadej]

Isn't the location of the store configurable?

[dcoutts]

Yeah but I don't want to check in tarballs to the repo ;)

They can be tiny, smaller than our large collection of integration test files :-)

[ezyang]

Well, my point is that they're difficult to edit and poorly supported by Git.

Actually, in an ideal world, we would probably have some single file format for declaring self-contained packages. One can dream...

[ezyang]

OK, this got rolled up in #4124; see commit "Support for configuring repositories in tests."