Sandbox targets can prevent reinstallation of packages with setup dependencies

[grayjay]

While experimenting with the custom-setup section, I was unable to reinstall a package that depended on two versions of another package. The list of targets in the -v3 log contained all of the installed packages, as well as a second occurrence of the main package. The extra target seemed to prevent the solver from choosing setup dependencies.

I wrote some tests that demonstrate the behavior. The unit tests show the effect of duplicate targets, and the integration test reproduces the problem in a sandbox. I'm not sure if this is a bug in sandboxes or the solver.

EDIT: The integration test installs the two dependencies in the sandbox, but I got a similar error when they were installed globally.

Tests: grayjay@42a8bd1
Log: https://ci.appveyor.com/project/grayjay/cabal/build/1.0.78

Unit test database:

  [
       Right $ exAv "A" 1 [ExAny "B"] `withSetupDeps` [ExFix "C" 1]
     , Right $ exAv "B" 1 []          `withSetupDeps` [ExFix "C" 2]
     , Right $ exAv "C" 1 []
     , Right $ exAv "C" 2 []
  ]

Installing A and B:

targets: A, B
[...]
[__0] trying: A-1.0.0 (user goal)
[__1] trying: B-1.0.0 (user goal)
[__2] next goal: A-setup.C (dependency of A-1.0.0)
[__2] rejecting: A-setup.C-2.0.0 (conflict: A => A-setup.C==1.0.0)
[__2] trying: A-setup.C-1.0.0
[__3] next goal: B-setup.C (dependency of B-1.0.0)
[__3] rejecting: B-setup.C~>A-setup.C-1.0.0 (conflict: B => B-setup.C==2.0.0)
[__3] trying: B-setup.C-2.0.0
[__4] done

Specifying each target twice:

targets: A, A, B, B
[...]
[__0] trying: A-1.0.0 (user goal)
[__1] trying: A~>A-1.0.0 (user goal)
[__2] trying: B-1.0.0 (user goal)
[__3] trying: B~>B-1.0.0 (user goal)
[__4] next goal: A-setup.C (dependency of A-1.0.0)
[__4] rejecting: A-setup.C-2.0.0 (conflict: A => A-setup.C==1.0.0)
[__4] trying: A-setup.C-1.0.0
[__5] next goal: B-setup.C (dependency of B-1.0.0)
[__5] rejecting: B-setup.C~>A-setup.C-1.0.0 (conflict: B => B-setup.C==2.0.0)
[__5] rejecting: B-setup.C-2.0.0 (dependencies not linked: cannot make B-setup.C canonical member of {*A-setup.C-1.0.0,B-setup.C-1.0.0,C-1.0.0}; conflict set: B-setup.C, A, B)
[__5] rejecting: B-setup.C-1.0.0 (multiple instances)
[__4] fail (backjumping, conflict set: A-setup.C, B-setup.C, A, B)
[__3] rejecting: B-1.0.0 (multiple instances)
[__2] fail (backjumping, conflict set: A-setup.C, B-setup.C, A, B)
[__1] rejecting: A-1.0.0 (multiple instances)
[__0] fail (backjumping, conflict set: A-setup.C, B-setup.C, A, B)

[23Skidoo]

Can this be solved by simply deduplicating the list of targets?

[grayjay]

I don't know. I didn't understand why the solver linked the unqualified goals and rejected B-setup.C-2.0.0 in the second run.

[grayjay]

@23Skidoo It looks like the open solver pull requests allow the solver to handle duplicate targets.

[grayjay]

@23Skidoo Do you mind if I create a label for issues with build type Custom?

[23Skidoo]

@grayjay Not at all, please go ahead.

[grayjay]

Thanks. How about "custom-setup"?

[23Skidoo]

SGTM.