GitLab

Now uses a single code path for both modes.

Eg can use cabal install foo --log-builds='$pkgid-$compiler.log'
and the build log for each package will written to a separate
file. If an existing file is given then the log is appended.
This or something like it should help in future with build
reporting of the non-anonymous kind.

The path to the binary we're running must be accessable from
that other directory. The fix is to use currentDir </> setup

Rather than calling inDir directly.

For the internal method, change to the right working dir if necessary.

Except for optionDryRun which is shared with another command.

or for using a diiferent initial working directory. We already
need to use a different working dir and this would allow us to
spawn multiple setup processes for parallel builds each with
their own working dir. Also, we want to be able to capture the
output of builds. At the moment our internal logging framework
is not capable of redirecting, but if we launch a process we
redirect its output to a file. This should be useful for build
reporting where we want logs for each individual package.

And tidy some imports slightly

Should now return a proper error rather than an internal
error from the HTTP library.

User installs by default elsewhere. Note that this default only
affects new config files. Existing windows users will need to
change their config file or delete it and let it be re-created.

The bogusResolver is used for compilers like hugs and nhc98 where
we do not know what packages are already installed. We do it by
altering the descriptions of the packages we're going to install
to remove all of their dependencies. Doing this gives us a valid
install plan. We rely on hope to minimise the difference between
this install plan and reality.

Takes account of the ProxyEnabled reg key
Allow proxy uris that lack the http:// uri schema.
This should really be moved into the HTTP package.

so it now actually works to say: $ cabal install foo -fbar

We don't actually have per-package flags yet. All -f flags
on the install/upgrade command line apply to every paclage.

Don't bother putting the server url into each report
since we do not want to upload that information anyway.

and add a function to parse a whole logfile of reports

This is so that we remember which server to send the reports to.
This is pretty important if you're using a private as well as a
public hackage server.

Instead of just using the latest version we use the best version
according to the following preferences in priority order:
- the same version as cabal-install was itself built with
- the same major version number as cabal-install was built with
- a stable version of Cabal (even second digit of major number)
- the latest version

The available package index is loaded lazily so if we can avoid
forcing all the packages then we can save a huge amount of slow text
parsing. So select out the maximal subset of the index that we could
ever need based on the names of the packages we want to install. For
the common case of installing just one or two packages this cuts
down the number of packages we look at by a couple orders of
magnitude. This does not help with the installed index which is read
strictly, though most people do not (yet) have hundreds of installed
packages, so that's less of an immediate problem.