haskell-ci breaks with source-repository-packages

[RyanGlScott]

I have a project (blank-canvas) with a source-repository-package in its cabal.project file:

packages: .
          ./examples

source-repository-package
  type: git
  location: https://github.com/ku-fpg/remote-monad
  tag: 3761a8ad889e9bd06a562d36cafb182513dbb6e1

However, haskell-ci does not appear to pick up on this information, as demonstrated by this failing Travis run:

$ cabal new-build -w ${HC} ${TEST} ${BENCH} --project-file="cabal.project" --dep -j2 all
Resolving dependencies...
cabal: Could not resolve dependencies:
[__0] trying: blank-canvas-0.7 (user goal)
[__1] next goal: remote-monad (dependency of blank-canvas)
[__1] rejecting: remote-monad-0.2, remote-monad-0.1.0.1, remote-monad-0.1.0.0
(conflict: blank-canvas => remote-monad==0.5)
[__1] fail (backjumping, conflict set: blank-canvas, remote-monad)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: blank-canvas, remote-monad

It seems that haskell-ci is generating its own cabal.project file on each Travis run but is failing to copy over source-repository-package information from the original cabal.project file.

Unfortunately, this means that blank-canvas is completely unusable at the moment with haskell-ci.

[RyanGlScott]

This somewhat ties back to #129, since other options specified in your cabal.project file (e.g., library-coverage: true) are not copied over to the per-run cabal.project files.

[philderbeast]

@RyanGlScott thanks for referencing the gnarly workaround.

[RyanGlScott]

Besides #186, my temporary fix for this issue (referenced in ku-fpg/blank-canvas@e04f31c) has uncovered another issue with haskell-ci: namely, that the use of all can cause more compilation than intended. Here is a snippet from a recent Travis run of singletons, which lists th-desugar as a source-repository-package:

$ cabal new-build -w ${HC} ${TEST} ${BENCH} all
Cloning into '/tmp/dist-test.LnFm/dist-newstyle/src/th-desugar-659e8e1f681e079'...
remote: Enumerating objects: 40, done.
remote: Counting objects: 100% (40/40), done.
remote: Compressing objects: 100% (29/29), done.
remote: Total 1864 (delta 16), reused 22 (delta 7), pack-reused 1824
Receiving objects: 100% (1864/1864), 546.98 KiB | 24.86 MiB/s, done.
Resolving deltas: 100% (987/987), done.
HEAD is now at 567145e... Preemptively version number to 1.10
Resolving dependencies...
Build profile: -w ghc-8.6.2 -O1
In order, the following will be built (use -v for more details):
 - accept-all-0.1 (exe:accept-all) (first run)
 - th-desugar-1.10 (lib) (first run)
 - th-desugar-1.10 (test:spec) (first run)
 - singletons-2.6 (lib:singletons, test:singletons-test-suite) (first run)

The fact that th-desugar's test suite is being built is deeply surprising to me, since I only intended for --enable-tests to encompass singletons' test suite. (Note that accept-all is from another .cabal file in the singletons repo, so it's expected for it to show up there.)

It's unclear to me if this is an intended consequence of the semantics of cabal new-build all + source-repository-packages (and whether this is being influenced by the haskell/cabal#5586 bug or not). Regardless, it would be worthwhile to come up with a suitable workaround in the meantime. Perhaps haskell-ci should explicitly enumerate the build targets it intends to build (e.g., cabal new-build lib:singletons test:singletons-test-suite lib:th-desugar exe:accept-all) so that it does not accidentally bring in additional, unwanted components, such as the test suites of source-repository-packages.

[RyanGlScott]

By sheer coincidence, someone else was having the same problem that I reported (in #184 (comment)) over here. Luckily, there's a relatively simple workaround documented here: just add the following to your generated cabal.project file alongside each source-repository-package:

package foo
  tests: False
  benchmarks: False

This is certainly much simpler than enumerating each individual target to build, at the very least.