CODEWITHSUNDEEP
haskellhaskell-stackhappstack
mherzl
mherzl

Reputation: 6220

How to deal with a Haskell package's configured dependency range being out-of-date?

When attempting to install happstack via

$ stack install happstack

I get the following error:

    Run from outside a project, using implicit global project config
Using resolver: lts-7.2 from implicit global project's config file: /Users/matthewherzl/.stack/global-project/stack.yaml

While constructing the build plan, the following exceptions were encountered:

In the dependencies for happstack-7.0.2:
    happstack-server-7.4.6.2 must match >=7.0 && <7.4 (latest applicable is 7.3.9)

Plan construction failed.

It appears that happstack requires an older-than-most-recent version of happstack-server. How should I deal with this issue?

Potential fixes I've considered:

  1. manually change happstack's config on my system, allowing it to depend on the latest version of happstack-config, and assuming that it can.
  2. installing an older version of happstack-config.
  3. find happstack source repo, validate that it works with latest version of happstack-config, update config to allow it to depend on most recent version, and submit pull request with config change to happstack's central repo.

I am not sure how to do any of these, #3 in particular sounds challenging.

Upvotes: 2

Views: 159

Answers (1)

duplode
duplode

Reputation: 34398

I will initially assume that you are aware of the difference between Hackage and Stackage. If that is not the case, let me know, so that I can explain it in the answer.

If you go to the Stackage page for LTS 7.2, the resolver/snapshot being used by your global configuration, you will see that the package happstack is not among the packages of that snapshot. Then, if you check the Hackage documentation for the happstack package, you will see a note saying that it was "deprecated in favor of happstack-server". That being so, all you have to do is installing happstack-server rather than happstack. (A general advice for such situations is always checking the documentation in Hackage and/or Stackage, as it can give a clearer picture of what is going on, as well as extra information on the package versions and dependencies that might be causing yo trouble.)

A few words on the three alternatives you thought of. If you have an old package that only needs trivial changes (say, bumping dependency bounds -- if the changes are more substantial you might be better off looking for an older, compatible snapshot) to be built with a recent Stackage snapshot, approaches #1 and #3 are not only good ideas but explicitly supported by Stack. As explained in the Stack documentation (look for packages, extra-dep and extra-deps options), you can configure your project so that, rather than the default versions in a Stackage snapshot, you use different versions from e.g. Hackage, a local Git repository or a remote Git repository. If you ever need to do #3 to adjust some package, you don't even need to wait for upstream to accept your pull request -- just configure Stack to pull the dependency from your fork in GitHub or elsewhere.

Upvotes: 3

Related Questions