Handle apparent package dependency cycles due to test suites / benchmarks

[tibbe]

Update by @ezyang: See @edsko's comment at #1575 (comment) we don't actually want to dep solver for each package individually, according to @dcoutts.

Update by @dcoutts: the latest iteration of idea 1 below is as follows:

Suppose for sake of argument we're looking at bytestring which has a test suite that uses tasty, and tasty depends indirectly on bytestring. So the original proposal was to resolve this cycle by building the under-development bytestring and then building tasty against that, and then building the bytestring testsuite against the freshly built tasty package. But actually this is crazy, it means every time I make a small edit to bytestring and want to re-run the tests, cabal has to go and rebuild tasty (and all the other deps of tasty that use bytestring). This would get really annoying really quickly. Also, we don't really want to build tasty against an in-development version of bytestring, we want tasty to use a stable version of bytestring. So much better is to have tasty be built using an existing stable bytestring. Then tasty etc does not need to be rebuilt as we make minor changes to the in-development version of bytestring.

So this requires we have a solution using two different version of bytestring. We already have something like this for dependencies of Setup scripts, which we call "independent" dependencies. So we can treat the dependencies of the test-suite /which it doesn't share with the library/ as independent. See #3422 for a partial implementation of this idea and a discussion of the difficulties.

Idea 2 below would require a different approach. In general it is important to have consistent behaviour of code in one component (e.g. exe) vs another component in the same package. This is what authors generally expect. This means that two exes both use some lib then they need to use the same version of that lib. If authors really want to allow two exes in the same package to use different versions of some dep then this ought to be explicit and we should come up with some mechanism to do so. If we go down this route then we should also consider the case of the same component using two different version of a lib. We might handle that like package qualified module imports, giving each one a different local name. This also relates to backpack.

---

I think we should create the install plan on a component (i.e. library, executable, test-suite, and benchmark) basis instead of creating one for the whole package.

There are two use cases I can think of:

1. There's a growing number of packages (anything that's a dependency of either test-frame-work and its related packages or of criterion) that can't have test suite or benchmark sections, as that would create a dependency cycle.
2. Users have requested being able to build executables (in a single package) that have conflicting dependencies.

I suggest that we treat each component as if it was a "package" with name package-x.y.z.w:component-name, for the purpose of dependency resolution.

[23Skidoo]

+1, this would be nice to have.

[ygale]

#1532 might be another reason this would be a good idea.

[kosmikus]

I don't think that the solver-part would be really hard. But we need to be able to build and install the components separately, otherwise this is worthless.

[23Skidoo]

But we need to be able to build and install the components separately, otherwise this is worthless.

With 1.18, we have this for build. I think that we don't need per-component install. The use cases Johan mentions don't actually require splitting packages other than the install target (one can only depend on libraries anyway, and there's guaranteed to be only a single library per package). We only need a way to selectively enable components with configure; for tests and benchmarks we already have that with --enable-tests and --enable-benchmarks.

So it looks to me that both use cases can be supported with no changes to the solver, only by splitting the install target into several virtual packages. Example of the first use case:

$ cd /path/to/$pkgid
$ cabal install --only-dependencies --enable-benchmarks --enable-tests
# Runs 'cabal install --only-dependencies $pkgid:library $pkgid:benchmark[0..N] $pkgid:test[0..N]' under the hood
$ cabal configure --enable-benchmarks --enable-tests
# Succeeds, since each component is treated as a separate package

For building a subset of exes something like configure --enable-component=foo,bar,baz will have to be added. Again, this will be needed only for the current target. Not sure if we want to allow installing such partially-configured packages with cabal install.

[ygale]

In #1541 you have a use case with two targets, A and B, with A an executable used as a preprocessor for the source code of library or executable B. A must be built and installed (or at least made accessible at some predictable path) before B is built.

[23Skidoo]

@ygale

In #1541, all you want is to build A before B (A and B don't have conflicting dependencies). This should be possible to fix on the component graph level (since they are both a part of the same package), once there's a way to declare that B depends on A.

#1532 seems to be unrelated.

[ygale]

Yes, you are correct that in our case it happens that there are no conflicting dependencies. But that is certainly possible. So this is another use case.

Also, here you need access to the compiled executable for A before beginning to build B, so there needs to be some kind of "install" step for A before B is built. It doesn't necessarily need to be the same thing as cabal install, but the salted dist directory is not suitable.

[23Skidoo]

Also, here you need access to the compiled executable for A before beginning to build B, so there needs to be some kind of "install" step for A before B is built.

A only needs to be in PATH. I believe that this works now since you said that that worked with 1.16.

[23Skidoo]

Related: @edsko's work on independent goals (#2531, #2530, #2515, #2514, etc.) and this comment by @kosmikus.

[edsko]

With my work on fine grained dependencies in the solver, the solver part of this should be relatively easy. The harder part would be to change the way the installer works.

[edsko]

Incidentally, the testsuite use case mentioned by @tibbe can be addressed in a simpler, if not quite as general way: we can treat the dependencies of the test-suite which it doesn't share with the library as independent. This would make it possible to have, say, a tasty testsuite for optparse-applicative even though tasty depends on optparse-applicative.

Without changing anything else, this would mean we can then link tasty to an another (probably older) version of optparse-applicative than the one we are testing. (It would require the optparse-applicative test suite to use the src/ dir of its main library directly, rather than have an internal dependency on the optparse-applicative library).

This is something I've previously discussed with @dcoutts and it should be quite easy to do know do (I'm not sure I'll have time left to do it though).