GitLab

It shares most code anyway.
Also fixes ticket #260 becuase we use the right entry point now.

Also change so that instead of giving the available package with
the highest version number (where that is higher than the installed
package) it gives us a dependency on a version of the package that
is strictly greater than the one installed. This is more flexible
since when resolving we do not necessarily have to pick the very
latest version if that turns out not to be possible.

It's clearer what is the generic stuff and what is specific to the
current resolver. So it should be a bit easier to swap in new ones.

Which seems to be the normal convention.

That is the standard naive dep resolver and the bogus one that has to
make up a plan assuming that all dependencies are installed.

and add a wrapper that makes InstallPlans

So kind of like uncons style rather than null and head.
It returns all the ready ones by lazily so it's no extra expense.
It'll allow parallel installations since all ready packages are
independent of each other. Also update callers.

Previously each layer called the next layer down and therefore the
top layer had to take all of the params that the bottom layer needed
even though they were mostly or wholly unmodified on the way down.
Now each layer takes the next layer as a parameter so we do not need
to take the params that are not used directly by the current layer.
The overall stack is then built by applying each layer to the next.

Four of the executeInstallPlan param were just passed through directly
to installPkg so this decouples them a bit.

They share most code so pull the first and last bits out into the
top level install function. They now need 2 and 3 fewer params
respectively, which is a good sign. Rename them because they're
generating plans now rather than doing the installation directly.

It's not actually specific to the InstallPlan.

Stops us from choosing them which would always end up with an
invalid installation plan.

It can take a while, especially with debug checks turned on.

It was finding all the dependencies of the failed package and
marking them as failed. But of course what we have to do is find
all the packages that depend on the failed package (the reverse
dependencies) and mark them as failed. We use the reverse
dependency Graph that we saved in the InstallPlan.

Simplifies implementation of completed and failed

Uses Data.Graph and annoyingly we also need to keep functions
around for mapping between Graph.Vertex <-> PackageIdentifier

For example it's not allowed for installed packages to depend
on configured packages.

Otherwise the dependency resolver may decide to pick the installed
instance of the package but we really do want to install the local
version. So to remove that choice from the dep resolver we just
delete it from the installed package index.

If we're in verbose mode then always print what we're going to
install, not just when the user specifies --dry-run.

The dependency resolver has had to be extended in a slightly hacky
way to gather the extra information needed by an install plan. In
particular it requires the flags to use to configure each package,
the actual versions of dependencies to use and all of the
installed packages and their closure of dependencies.
However the current resolver is fairly naive and so can be easily
persuaded into producing an invalid install plan, in which case
you'll get a detailed list of reasons as to why it is invalid.

Instead of just reporting that a plan is invalid, produce a
detailed list of reasons why it is invalid.
This should be useful for people debugging dependency resolvers.
Also rename the complete property to closed, since the property
is about the set being closed under the dependency relation.
Also re-use the PackageIndex functions for checking the validity
conditions rather than re-implementing the checks locally.

Fixes ticket #268. And use newtypes for the username and password,
just to be more sure we're not mixing them up with other strings.

The local variant was for the case that we were starting from a package
description rather than a dependency to a named package. In the local
case we not only need to resolve the dependencies of the package but also
to find a flag assignment for the local package. This case crops up in
the resolver normally when we try to satisfy a dependency, we have to
pick a flag assignment for the dependency and resolve its dependencies.
It is annoying to have both entry points, especially as we want the
resolver to be plugable. So instead we define the local package as an
available package, then by resolving a single dependency on exactly the
name and version of the local package then we can get an install plan for
the local package. It also requires generalising installPkg to deal with
the local case.

Renamed to AvailablePackage since that what it is really.
Now instead of just representing packages from a remote hackage repo
it includes an alternative for a local unpacked package. In future
we should add more alternatives, eg for other local packages (ie not
just the one that's unpacked in the current dir) and for remote
packages in source control like darcs, git etc.

And refactor slightly to batch some of the misc parameters
together in a record rather than passing them all separately.

It's used to select which version of the Cabal lib to use when
configuring, building and installing packages. It's mainly so that
we can use cabal-install to help us test that packages build ok with
both old and new versions of the Cabal library. In particular we'd
like to check every package on hackage to make sure that new Cabal
versions are not breaking packages that worked with older versions.