4

The recent Travis CI build of the development version of my Haskell package reports the error

MissingH must match >=1.3.0.1, but the stack configuration has no specified version (latest matching version is 1.4.0.1)

when building for GHC 8.6.1, even though I have 

MissingH >=1.3.0.1

in my build-depends.

I don't understand this error: it seems contradictory. I have no upper limit on MissingH, so why is it erroring and not using the latest?

orome
  • 45,163
  • 57
  • 202
  • 418

1 Answers1

7

You need to add MissingH to stack.yaml.

extra-deps:
  - 'MissingH-1.4.0.1'

  • Your package's *.cabal file says what versions of dependencies are compatible with your package. It is a loose specification, not all combinations may actually work (because they may have conflicting bounds on transitive dependencies, or there is some unforeseen breakage with a particular version you haven't tested with).

  • In contrast, stack.yaml describes a particular snapshot of packages, pinned to specific versions. This precisely says "my package is known to work with those versions". Of course, it is tedious to maintain the version of every dependency, and for that the Stackage team maintains a "resolver", a curated set of package versions known to work together, that you can use to specify the version of many packages at once, by setting the resolver: field of stack.yaml appropriately. A resolver only lists a subset of packages on Hackage, so when one of your dependencies is not in there, you need to add it to your stack.yaml as an extra-dep.

Update: following the discussion, some more details about configuring travis are necessary.

First, my current preferred solution for CI of Haskell projects is to not bother with stack and use instead https://github.com/haskell-CI/haskell-ci which generates a travis script using cabal-install.

Now for a less radical solution.

Currently the travis script is only varying the --resolver option, but as far as I can tell there is no command line option to add an extra-dep. It seems stack.yaml files are the only way for that. Furthermore, we only want to specify MissingH as an extra-dep for the latest nightlies, because LTS'es already include it.

Thus I suggest the following:

  1. Create a separate stack.yaml for the nightly resolver only, call it something else since you already have one, for example stack-nightly.yaml

    packages:
- .
extra-deps:
- 'MissingH-1.4.0.1'

  2. Set an environment variable to point to stack-nightly.yaml when the resolver is a nightly, maybe:

    env:
...
- $RESOLVER=nightly STACK_YAML=stack-nightly.yaml
# Not sure of the syntax.

    Otherwise you can use the --stack-yaml command line option.

Li-yao Xia
  • 31,896
  • 2
  • 33
  • 56
  • Won't that add MissingH-1.4.0.1 each of the builds listed in my `stack.yaml`? The problem is that doing that for the (current) `nightly` appears to be essential; but doing it for any (currently) older LTS will be wrong (since it won't really be building against that LTS anymore). – orome Oct 01 '18 at 19:46
  • I see, that's an extra-dep only for the new nightly. You can change the travis script to add the extra-dep only in that case, for example by checking in a custom `stack-ghc-8.6.yaml` and pointing stack to it with the `--stack-yaml` command line option. – Li-yao Xia Oct 01 '18 at 20:05
  • But that needs to be in the `.cabal` for it to correctly describe how the package will build in the presence of each LTS, right? Perhaps what I need is [something conditional in the `.cabal`](https://stackoverflow.com/a/35662514/656912), but I'm not sure how to express it. – orome Oct 01 '18 at 21:13
  • The problem here is that `MissingH` is not in a snapshot you're using. This is irrelevant to `*.cabal`. – Li-yao Xia Oct 01 '18 at 21:20
  • I’m using several snapshots, but can only have 1 cabal file which needs to work with all of them, as is (not by adding something externally). – orome Oct 01 '18 at 21:28
  • Sure, that's how it works, and there is generally no need to tweak the cabal file. "how the package will build in the presence of each LTS" - that is not what the cabal file is meant to describe. All you need is to setup travis to use a different `stack.yaml` for `nightly-2018-10-01`. This shouldn't affect the cabal file. – Li-yao Xia Oct 01 '18 at 21:39
  • My `stack.yaml` isn't used at all by Travis (is it?). What I need is a conditional way of adding `MissingH` to the packages provided in LTS, but only when GHC >= 8.6.1, in my `travis.yaml`. – orome Oct 02 '18 at 21:46
  • Travis does use `stack.yaml`, `stack`'s `--resolver` option only overrides the `resolver:` field but not the others. I have already mentioned you can create a separate yaml file for the latest nightly resolver that includes `MissingH` and change the travis script to use it. – Li-yao Xia Oct 02 '18 at 21:55
  • Got it (finally, sorry). So the crux of the answer then needs to be: how to get the `travis.yaml` to use a different `stack.yaml` depending on the value of `$RESOLVER` (whether or not its in a list of possible values). – orome Oct 02 '18 at 22:16
  • BTW, when I do add the extra-dip, the [relevant build](https://travis-ci.org/orome/crypto-enigma-hs/jobs/436372956) still gives and error: `Could not find module ‘Data.String.Utils’` – orome Oct 02 '18 at 22:19
  • 1
    This conditional is making it so that the package doesn't depend at all on `MissingH` with GHC 8.6. You do not need a conditional here at all. I will update my answer to give more details about configuring Travis. – Li-yao Xia Oct 02 '18 at 23:14