Closed matthewkaney closed 7 months ago
@mindofmatthew thanks for getting in touch about this. I've put out a 0.3.2.2 update of Haskellish that widens the bounds on template-haskell and mtl and appears to build just fine with LTS 22.8. I think it should now suffice just to change the haskellish reference in Tidal's top level stack.yaml to 0.3.2.2. (Estuary doesn't depend on a stack build of tidal-parse, though, FWIW.)
@mindofmatthew I don't know too much about it either and don't use stack myself. I think it is good for tidal to compile against the latest LTS though. I maintain the tidal package on stackage which involves making sure tidal works with the particular set of hackage libraries in each stackage release (basically I get a github notification when a library version is bumped and I have to increase tidal's upper bounds for that dependency). One win from this is tidal eventually makes it to debian.
Another build issue, this time with the Stack resolver.
Our CI action does a test run of Stack against the latest resolver version. As of Stackage releasing LTS Haskell 22.0, the version of Haskell got updated, which updated
mtl
, which broketidal-parse
becausehaskellish
depends on an old version ofmtl
.@yaxu, do you know anything about the Stack build/resolver and/or who might use it or have opinions on it? I don't know Stack at all, but is there a reason to not try and resolve it against a fixed version of LTS Haskell? ndr_brt (not tagging because I already chatting with them about it on Discord) did the last editing on the code in question, but doesn't remember any of the specifics.
@dktr0, do you depend on the Stack build of
tidal-parse
or have any thoughts on themtl
dependency issues? Estuary is the only major user oftidal-parse
if I'm not mistaken.The relevant error, for what's it worth: