Today in Cabal, when you build and install a package, it is
uniquely identified using an InstalledPackageId which is computed
using the ABI hash of the library that was installed.  There
are few problems with doing it this way:

    - In a Nix-like world, we should instead uniquely identify
      build products by some sort of hash on the inputs to the
      compilation (source files, dependencies, flags).  The ABI
      hash doesn't capture any of this!

    - An InstalledPackageId suggests that we can uniquely identify
      build products by hashing the source and dependencies of
      a package as a whole.  But Cabal packages contain many components:
      a library, test suite, executables, etc.  Currently, when
      we say InstalledPackageId, we are really just talking about
      the dependencies of the library; however, this is unacceptable
      if a Cabal package can install multiple libraries; we need
      different identifiers for each.

    - We've also needed to compute another ID, which we've called
      the "package key", which is to be used for linker symbols
      and type equality GHC-side.  It is confusing what the distinction
      between this ID and InstalledPackageIds are; the main reason
      we needed another ID was because the package key was needed
      prior to compilation, whereas the ABI hash was only available
      afterwards.

This patch replaces InstalledPackageId and PackageKey with a
new identifier called ComponentId, which has the following
properties:

    - It is computed per-component, and consists of a package
      name, package version, hash of the ComponentIds
      of the dependencies it is built against, and the name
      of the component.  For example, "foo-0.1-abcdef" continues
      to identify the library of package foo-0.1, but
      "foo-0.1-123455-foo.exe" would identify the executable,
      and "foo-0.1-abcdef-bar" would identify a private sub-library
      named bar.

    - It is passed to GHC to be used for linker symbols and
      type equality.  So as far as GHC is concerned, this is
      the end-all be-all identifier.

    - Cabal the library has a simple, default routine for computing
      a ComponentId which DOES NOT hash source code;
      in a later patch Duncan is working on, cabal-install can
      specify a more detailed ComponentId for a package
      to be built with.

Here are some knock-on effects:

    - 'id' is a ComponentId

    - 'depends' is now a list of ComponentIds

    - New 'abi' field to record what the ABI of a unit is (as it is no longer
      computed by looking at the output of ghc --abi-hash).

    - The 'HasInstalledPackageId' typeclass is renamed to
      'HasComponentId'.

    - GHC 7.10 has explicit compatibility handling with
      a 'compatPackageKey' (an 'ComponentId') which is
      in a compatible format.  The value of this is read out
      from the 'key' field.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Use a common sandbox for building Cabal and cabal-install.

[ci skip]

Always use new hackage URI

This commit fixes the handling of repo URIs that have a non-null uriPath.
Previously, the code would just override the uriPath if the repo had one.
For example, "http://hackage.haskell.org/foo" as repo would lead to the upload URI
"http://hackage.haskell.org/upload".

Even using `parseRelativeReference "upload"` (instead of "/upload") doesn't work, since
that will replace the last path component of the URI path (i.e. "/foo/bar" would generate
the URI "/foo/upload", but we want "/foo/bar/upload").

Previously, when uriPath was "", then the generated URI would be wrong. For example,
if we have a remote repo with the URI http://hackage.haskell.org (without a trailing slash),
then the previous code will generate http://hackage.haskell.orgupload for the upload URL.
We now use the relativeTo function from Network.URI, which does the right thing.

Additionaly, we now always rely on the new hackage URL layout. cabal now automatically
upgrades the old URI to the new URI when parsing the config file, so manually checking
for that is no longer needed.

Carry package dbs into testsuite

Don't bootstrap Cabal, fixing #2845.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

This is necessary because otherwise doing a secure update will result in errors
such as

Unexpected response (4,0,4)for http://hackage.haskell.orgpackages/archive/root.json

Alternative we could set up redirections for these in Hackage, but what's the
point?

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Prior to this patch, the testsuite used your global package db, and
sometimes, the inplace package db, which led to errors if you didn't
have old-time installed globally. They looked like this:

BuildDeps/SameDepsAllRound:          Cabal result was Result {successful = False, success = Failure, outputText = "\"/home/enolan/cabal/Cabal/tests/Setup configure --user -w  /home/enolan/.nix-profile/bin/ghc\" in PackageTests/BuildDeps/SameDepsAllRound\nConfiguring SameDepsAllRound-0.1...\nSetup: At least the following dependencies are missing:\nold-time -any\n"}

Use extra-prog-path in running build-type configure

Add warning about testing Cabal on Windows

Prevent detailed-0.9 test suites from freezing on Windows (fixes #2762)

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

For a while now, we lift out dependencies from conditionals.  If a
package is dependended on regardless of the outcome of a test, the
dependency is lifted out. This has the advantage that we can choose an
instance for the package prior to choosing the value of the flag. Often,
this is the desired behaviour for flags, i.e., to have the flag choice
implied by the possible package choices, rather than the other way
around.

Prior to this change, lifting was simply adding an unconstrained
dependency to such a package at a higher level, which would then of
course still be refined after making the flag choice. We are now making
this more precise by actually computing the union of the ranges in both
branches of the conditional. So we will not choose an instance on the
top level that will later be rejected by both branches.

Add DeriveLift to Language.Haskell.Extension

Add hasUpperBound and hasLowerBound

This is useful for performing PVP bounds checking, especially for
tooling that wants to automate such dependency bounds. A demonstration
of this being used in practice is the --pvp-bounds flag for stack:

https://github.com/commercialhaskell/stack/commit/c774f9905b3b112f58fc3789dfb9c26389d33b24

Lower memory usage during index file parsing #2396

The parsePackageIndex wasn't streaming because resulting list was
hidden in two constructors: Either and tuple. By removing that error
semantics changed in updatePackageIndexCacheFile.

The updatePackageIndexCacheFile problem was sequence call that evaluated
whole list made by parsePackageIndex. By using lazySequence any error
during index file parsing will be raised during writing to cache file.

Also removed reacPackageIndexFile, as it wasn't used anywhere as far as
I can tell. If this is a mistake I'll include it again.

Revert "Exit with an error if $CABAL_SANDBOX_CONFIG does not point to extant file"

Call addInfoForKnownRepos in initialSavedConfig

We called addInfoForKnownRepos when _parsing_ a file, but not when creating the
initial file. This meant that when we created an initial file, we would end up
with a different internal configuration (which would not have
addInfoForKnownRepos applied) than if we wrote out and then read back that same
initial file (which would).

This reverts commit 3488f593.

Bump the upper bound on 'process'.