GitLab

Output the last error message in addition to the final conflict
set, and give a less technical description of the conflict set for the
user message.

An example for the expected output is:

> cabal install --dry-run DPM CurryDB DAV DSH Digit HList MagicHaskeller bamboo
cabal: Could not resolve dependencies:
trying: CurryDB-0.1.1.0 (user goal)
trying: base-4.8.0.0/installed-1b6... (dependency of CurryDB-0.1.1.0)
trying: unix-2.7.1.0/installed-e59... (dependency of process-1.2.3.0/installed-3b1...)
trying: directory-1.2.2.0/installed-b49... (dependency of process-1.2.3.0/installed-3b1...)
Dependency tree exhaustively searched.
I've had most trouble fulfilling the following goals: haskell98 (36850), base
(26359), directory (9599), HTF (5092), bamboo (3788), DPM (3452), unix (3208),
CurryDB (107)

Conflicts are sorted by conflict counts, so high-rated conflicts appear
early in the list. Currently the raw count is printed.

Keep information about the final conflict set and print it in case of
exhaustive search. The original error message is not printed any more.

bootstrap.sh: do not use -j on ghc-7.8

Cabal-1.18 in ghc-7.8 does not support -j

cabal-install integration-tests replacement omnibus patch

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

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

This fixes some "permission denied" failures on Windows,
but it would be a lot better to fix properly.  See the comment
in Test.Cabal.Monad for more details.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Otherwise, ghc-pkg will complain that it's reinitializing the
package database.

Possibly there is some refactor to make withPackageDb more robust
if it is called multiple times.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

TODO: This seems to cause Windows failure
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Previously, clients of runM had to explicitly record and check
the exit code of a run subcommand.  This has now been folded into
runM, so this is done always (which is what you wanted anyway.)
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Previously, in some cases we would carry around an explicit
FilePath for an executable that we wanted to invoke subsequently.

In this new scheme, any executable we want to execute gets registered
to the ProgramDb we are carrying around.  Now we can uniformly
use runProgramM in all cases.  Great!
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

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

Note: hackage-repo-tool doesn't build with Windows, so that
support is commented out.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

This is a pretty important new feature in the test suite, which
is to construct a remote repository on the fly as part of the
test suite.

The general principle is that you create a directory full of folders
for all of the packages you want available in the repo, and then
the 'withRepo' function will initialize this into a secure repo
you can do tests with.

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

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

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

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

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

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

TODO: This hacks HOME so that it works in CI which doesn't
have old-time available in system GHC, remove that hack eventually.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

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

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

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

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

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

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

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

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

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

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

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

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

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

A bit of trickiness here.  The high points:

    - We need to feed --with-compiler to cabal.config, NOT
      the flag, because sandbox doesn't know how to read in
      compilers except from the global config.  This is
      arguably a bug but I can't be bothered to fix it.

    - We need to NOT provide certain commands when we're
      in sandbox mode; this is controlled by testHaveSandbox.

    - Use withSandbox to start a session in the sandbox.
      It inits the sandbox for you.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

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

cabal-install depsolver doesn't know how to pick up preinstalled
internal components on a per-component build.  Moral of the story:
don't use cabal-install here; call Setup directly.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>