Allow "cycles" through test suite dependencies (VERSION TWO)

[ezyang]

This is a version of #3232 updated for HEAD.

CC @edsko

[23Skidoo]

If the tests pass, can you please squash fix-up commits with the original ones? Would be nice to avoid having broken commits in history.

[ezyang]

There's still a bug in this PR though, cabal install in the sandbox is not idempotent. In the integration test, if I run it the second time, here's what I get:

      In order, the following will be installed:
      A-2 *test (via: T-1) (reinstall) (changes: T-1 added)
      T-1 (via: A-2) (reinstall) (changes: A-1 -> 2)

UPDATE: and then the third time I run it, the dependency solver fails altogether:

      cabal: Could not resolve dependencies:
      next goal: A (user goal)
      rejecting: A-1/installed-3Pv..., A-1 (constraint from user target requires
      ==2)
      trying: A-2
      trying: A~>A-2 (user goal)
      trying: A~>A-2 (user goal)
      rejecting: A-2:!test (constraint from config file, command line flag, or user
      target requires opposite flag selection)
      trying: A-2:*test
      trying: A-test.T~>T-1 (dependency of A-2:*test)
      trying: A-test.A~>A-2 (dependency of A-test.T-1)
      rejecting: A-test.A-2:!test (constraint from config file, command line flag,
      or user target requires opposite flag selection)
      trying: A-test.A-2:*test
      fail (cyclic dependencies; conflict set: A-test.A, A-test.T, A-test.A-2:test)
      Dependency tree exhaustively searched.

      Note: when using a sandbox, all packages are required to have consistent
      dependencies. Try reinstalling/unregistering the offending packages or
      recreating the sandbox.

@23Skidoo Of course.

[grayjay]

The log from the third run looks like #3203.

EDIT: I think there are multiple A targets, but I don't know if that explains the failure:

  trying: A-2
  trying: A~>A-2 (user goal)
  trying: A~>A-2 (user goal)

[ezyang]

(I guess, at some point, we should move this to a branch on origin so @edsko can push to it.)

[23Skidoo]

So I think I won't delay the first 1.24 release for this. If @kosmikus thinks that this PR should go into 1.24, I think it can be made a part of a point release. Which means that 1.24 is now good to go.

[kosmikus]

Independently of the first 1.24 release, I'd like to understand better what is going on here. There's quite a bit of history, and perhaps someone who has been following that more closely than I have can provide a good summary of what the status here is? @ezyang ?

[ezyang]

I don't really know how the patch internally works, but I know that the obvious test for the feature (cabal installing a package with a cyclic dependency in a sandbox) doesn't work properly. So someone needs to dig in and figure out why it's failing and then fix it.

[23Skidoo]

the obvious test for the feature (cabal installing a package with a cyclic dependency in a sandbox) doesn't work properly. So someone needs to dig in and figure out why it's failing and then fix it.

@edsko, can you please look into it?

[edsko]

@23Skidoo the solver part of this is working, as far as I can tell. I'm not sure what's going on with the sandbox, some additional check somewhere I think. I don't know when I'll get a chance to look at that; perhaps somebody who is more familiar with the sandboxing stuff would be able to identify the problem more quickly?

[23Skidoo]

I don't know when I'll get a chance to look at that; perhaps somebody who is more familiar with the sandboxing stuff would be able to identify the problem more quickly?

I'll try to take a look at this next month.

[hvr]

@ezyang I wanted to to try this PR to see whether it fixes the issues I have with a couple of packages (time, bytestring, binary, cassava, ...) but sadly this PR has bitrotted and needs to be rebased with the merge-conflicts resolved...

[23Skidoo]

Closing in favour of #3402.

[23Skidoo]

@hvr See #3402 for an updated version.

[hvr]

@23Skidoo thanks!