Make Cabal accept --dependency flags qualified by components

[ezyang]

I propose to extend the --dependency to accept not just a mapping from package names to the IPID implementing them, but a qualified package name CNAME.NAME, permitting a dependency to be be applied to a specific component; e.g. --dependency foo-tests.p=p-0.1-aaa --dependency foo.p=p-0.2-bbb would request version 0.1 of p for the test suite, but 0.2 for the main library.

With this capability, instead of flattening dependencies when passing them from cabal-install to Cabal, we essentially transmit the the dependencies verbatim, allowing Cabal to understand solver results in which components were solved completely independently.

---

This ticket explains why PR #3232 does not solve the problem of "Users have requested being able to build executables (in a single package) that have conflicting dependencies" listed in #1575, and proposes an addition to the Cabal library which solves this problem.

First, let's review the operation of #3232: it permits "inconsistent" dependency graphs for test suites, the motivation being that if the test suite for optparse-applicative depends on both optparse-applicative and tasty; but tasty depends on optparse-applicative, we want to be able to use different versions of optparse-applicative (the old, stable version should be linked against the test suite library, and the test suite itself tests the new version.) These graphs are "inconsistent" because when we look at the transitive closure of dependencies for the test suite, we see two different versions of optparse-applicative.

There is an outrageous coincidence which means that it IS possible to convince the Cabal library to build this (despite cabal-install not understanding these plans): Cabal takes a list of --dependency flags, one per package name, which identify the direct dependencies of the package. So cabal-install simply conspires to call Cabal with --dependency tasty-1.0-aaa --dependency optparse-applicative-0.2-bbb; but actually tasty-1.0-aaa was built against optparse-applicative-0.1-ccc. Cabal will notice the inconsistency, but it won't error, and the package will build and run fine.

But coincidences are simply coincidences; there must be a case it does not work. @edsko's PR correctly notes where this doesn't work: in part (2), he says "we add qualifiers to the dependencies of a test suite section, but only those that are not shared with the main library (or are internal)." This rules out a case like this:

name: mypkg
library
  build-depends: p > 3.0
test-suite a
  build-depends: p <= 3.0

If the solver qualifies the p dependency in the test-suite, it could conclude that mypkg has these dependencies: an unqualified dependency on p-3.1, and a test suite qualified dependency on p-2.9. Then the solver has no way of transmitting this information to Cabal, --dependency p-3.1-JJJ and --dependency-0-2.9-KKK is right out because there is no way to tell which one is for the library, and which one is for the test suite. The problem is that --dependency flags are package-global, and cannot be given to components individually. So there needs to be a way to qualify a dependency per component.

By the way, #2725 is not a duplicate of this bug, because the user is asking for something less complex: they just don't Cabal to attempt to get dependencies for their unsatisfiable executable; they don't want to build all executables (it would be pretty hard to satisfy multiple mutually exclusive base bounds!) Also, why mypkg is a bit of a whacky package, there are less obvious situation where this might occur, in particular, if the different build-depends lists result in different constraints which end up being mutually exclusive (as alluded to originally in #1575.)

[23Skidoo]

SGTM.

[ezyang]

This is subsumed by per-component configure https://github.com/ezyang/ghc-proposals/blob/master/proposals/0000-componentized-cabal.rst