Strange dependency / build problems with cabal

[yaxu]

Cabal is failing for many people. This looks typical: https://toplap.lurk.org/t/i-cant-install-tidal/607/3

Even though the matrix looks fine: https://matrix.hackage.haskell.org/#/package/tidal as do the travis tests: https://travis-ci.org/tidalcycles/Tidal

[yaxu]

Any tips @hvr?

[hvr]

@yaxu, I had a very brief look at this, and I can say the MonadFail compile error is legit; it can easily be reproduced by e.g.

$ cabal v2-build -w ghc-8.2.2 --constraint 'parsec == 3.1.11'
Build profile: -w ghc-8.2.2 -O1
In order, the following will be built (use -v for more details):
 - tidal-1.0.13 (lib) (first run)
Preprocessing library for tidal-1.0.13..
Building library for tidal-1.0.13..
[16 of 22] Compiling Sound.Tidal.ParseBP ( src/Sound/Tidal/ParseBP.hs, /tmp/tidal/dist-newstyle/build/x86_64-linux/ghc-8.2.2/tidal-1.0.13/build/Sound/Tidal/ParseBP.o ) [Text.ParserCombinators.Parsec.Token changed]

src/Sound/Tidal/ParseBP.hs:401:24: error:
    • No instance for (Control.Monad.Fail.MonadFail
                         (Text.Parsec.Prim.ParsecT String () Identity))
        arising from a use of ‘readColourName’
    • In the first argument of ‘(<?>)’, namely ‘readColourName name’
      In a stmt of a 'do' block:
        colour <- readColourName name <?> "known colour"
      In the expression:
        do name <- many1 letter <?> "colour name"
           colour <- readColourName name <?> "known colour"
           return $ TPat_Atom colour
    |
401 |              colour <- readColourName name <?> "known colour"
    |                        ^^^^^^^^^^^^^^^^^^^

and if you look at

http://hackage.haskell.org/package/parsec-3.1.13.0/changelog

the MonadFail ParsecT instance was only added in parsec-3.1.12

and it appears that colour-2.3.5 started adding a MonadFail constraint to readColourName (which btw is not in accordance with the http://PVP.haskell.org, as changes to typesignatures demand a major version increment), see

https://hackage.haskell.org/package/colour-2.3.5/changelog

in other words, as soon as you have colour-2.3.5, you need parsec-3.1.12 (or later) or you'll get that build-failure...

Does this make any sense? :-)

PS: in other words, tidal's metadata needs to express the sound combinations of colour and parsec via version constraints; there's more than one way to accomplish this (dependening on the complexity you want to incur)

[yaxu]

Thanks @hvr that's really helpful. I've simply added a lower bounds of 3.1.12 to parsec for now.

[hvr]

@yaxu btw, this issue can still resurface due to old releases being more liberal with their bounds (because the cabal solver might decide it's more economical to backtrack to an older release in order to satisfy constraint than to use the latest tidal release); I'd suggest tweaking some of the previous tidal releases to exclude colour-2.3.5 -- I can take care of this if you want

[yaxu]

You'd be very welcome @hvr, thanks very much!

[yaxu]

Hmm now there are different problems reported..

[yaxu]

I wonder if it's actually the colour package that needs its dependencies fixing?

[yaxu]

Ah no, this just seems to be a 7.8.* version of ghc installed from 2014, which it seems tidal doesn't support any more with its base >=4.8 constraint https://wiki.haskell.org/Base_package

[hvr]

@yaxu yes, but if you'd ask cabal to install tidal from Hackage, it'd happily backtrack to a recent version that still supported GHC 7.8 (c.f. https://matrix.hackage.haskell.org/#/package/tidal@1560271811 ), such as tidal-0.9.5

$ cabal repl -w ghc-7.8.4 -zb tidal --dry
Resolving dependencies...
Build profile: -w ghc-7.8.4 -O1
In order, the following would be built (use -v for more details):
 - binary-0.8.7.0 (lib) (requires build)
 - bytestring-builder-0.10.8.2.0 (lib) (requires build)
 - colour-2.3.3 (lib:colour) (requires build)
 - mersenne-random-pure64-0.2.2.0 (lib:mersenne-random-pure64) (requires build)
 - primitive-0.7.0.0 (lib) (requires build)
 - safe-0.3.17 (lib) (requires build)
 - text-1.2.3.1 (lib) (requires build)
 - data-binary-ieee754-0.4.4 (lib:data-binary-ieee754) (requires build)
 - SHA-1.6.4.4 (lib) (requires build)
 - Cabal-2.0.1.1 (lib) (requires build)
 - hashable-1.2.7.0 (lib) (requires build)
 - entropy-0.3.8 (lib:entropy) (requires build)
 - unordered-containers-0.2.10.0 (lib) (requires build)
 - nats-1.1.2 (lib) (requires build)
 - stm-2.5.0.0 (lib) (requires build)
 - semigroups-0.18.5 (lib) (requires build)
 - integer-logarithms-1.0.3 (lib) (requires build)
 - async-2.2.2 (lib) (requires build)
 - parsec-3.1.13.0 (lib) (requires build)
 - case-insensitive-1.2.1.0 (lib) (requires build)
 - blaze-builder-0.4.1.0 (lib) (requires build)
 - scientific-0.3.6.2 (lib) (requires build)
 - streaming-commons-0.2.1.1 (lib) (requires build)
 - hosc-0.15 (lib) (requires download & build)
 - attoparsec-0.13.2.2 (lib) (requires build)
 - websockets-0.12.5.3 (lib) (requires build)
 - tidal-0.9.5 (lib) (requires download & build)

[yaxu]

Ok @hvr, but I really wouldn't want that to happen - 0.9.5 has a different API so wouldn't work with the rest of the tidal environment (editor plugins and so on)

[yaxu]

(Of course it's great that old versions will install, for people who have composed music in the past and want to preserve it)

[hvr]

@yaxu ...and that's why you should tell people to somehow record the API they composed their music against...that's what we have version operators for, so you can also say "I need any version of tidal compatible with tidal-0.9.5" -- that's what e.g. tidal ^>= 0.9.5 expresses (which would allow tidal-0.9.7 but not e.g. tidal-1.0.10 or tidal-0.10.1) :-)