Doesn't build with unliftio 0.2.0.0

[felixonmars]

The latest unliftio doesn't depend on resourcet anymore.

[  3 of 126] Compiling Stack.Prelude    ( src/Stack/Prelude.hs, dist/build/Stack/Prelude.dyn_o )

src/Stack/Prelude.hs:137:55: error:
    Not in scope: type constructor or class ‘ResourceT’
    |
137 | runConduitRes :: MonadUnliftIO m => ConduitM () Void (ResourceT m) r -> m r
    |                                                       ^^^^^^^^^

[snoyberg]

This will be fixed when we update the stack.yaml files. Is there a reason you're running into this issue?

[felixonmars]

We are updating monad-logger on Arch, but old unliftio doesn't build with the new version. Updating also unliftio causes build failures of stack.

[snoyberg]

Please build Stack with the stack.yaml provided in this repository, not with an arbitrary set of dependencies. There have been a number of bug reports that have been difficult to track down due to random versions of Stack (straight off of master) and arbitrary dependencies making it into Arch. It's all but impossible to diagnose problems when we don't know what versions of dependencies have been used.

[felixonmars]

I see. Since we are more like Stackage nightly it is impossible to keep different dependencies for different packages. If you feel this is not ideal for stack anyway, I'll remove the stack package from Arch.

[borsboom]

Bear in mind that Stack is is not a Haskell library, it's just a program that happens to be implemented in Haskell that is intended to be statically linked with the Haskell libraries it uses. There's no inherent reason why the versions of dependencies used to build Stack need to be the same as the Haskell libraries used to build other packages and libraries on a system. Indeed, that's one of the main purposes of Stack: that different projects should safely be able to have different dependency versions. Cabal sandboxes exist for the same reason.

[borsboom]

BTW, Stack has also tended not be be in Stackage for the same reason. That being said, we're going to make an effort to keep it up to date with Stackage nightly starting from the imminent v1.6 release.

[felixonmars]

Many C programs are also statically linked upstream and made dynamic-linked by distributions, too. If there is some will to keep it up to date with Stackage nightly, we can still keep the Arch package. I also opened a bunch of pull requests for this before.

[Blaisorblade]

Many C programs are also statically linked upstream and made dynamic-linked by distributions, too.

Just for the record, that does not seem an argument per se — actual issues with binary size might be — and it does seems pretty different. Last I used Linux, when distros link program X dynamically you usually don’t, say, port it across different Qt APIs/ABIs, or viceversa; during transitions they often ship both, and those happen pretty seldom. I’m ignoring when distros sponsor the porting or in-house development (not the case here). Stack depends on many smaller packages that change API/ABI much more frequently.

[felixonmars]

Since I am the Qt maintainer of Arch myself, I actually did port projects and submit patches to upstream rather frequently. Some DE integration plugins use private Qt headers and can easily break across minor version bumps. We do ship both Qt4 and Qt5 at the same time (as it's usually a nearly complete rewrite to port), but never Qt 5.8 and Qt 5.9. If I understand correctly, most API/ABI change between minor versions should not be too hard to port, even with haskell libraries, so I often do that and submit patches if upstream is busy.

It is indeed a problem if upstream doesn't intend to follow updates of their dependencies at all, that's why I dropped purescript [1]. I am glad to help if it is not the case for stack :)

[1] https://github.com/purescript/purescript/pull/3032#issuecomment-321287073

[Blaisorblade]

I am not too familiar with Haskell on Arch beyond the reports that Google finds so I don’t have a qualified opinion, but please let me answer in general.

I was indeed ignoring in-house development by distros, which is what you’re doing for Qt; if a distro does the appropriate quality assurance itself (the same as upstream) or getting patches approved by upstream, that’s valid. If actual changes are treated as “not too hard” there’s a problem. I’ve stopped using Gentoo years ago after some maintainer seemed to think porting a kernel patch was not too hard and introduced deadlocks that (I thought back then) should be easy to spot for a kernel dev.

But changing dependencies (not just on Arch) has a history of introducing bugs that are only caught in the wild — that’s what @snoyberg remarked above, and seems concerning.

As I don’t know what Arch Linux’s QA policy is, I can’t comment on it. I’ll let the other Stack devs reply on Stack plans.

[borsboom]

If I understand correctly, most API/ABI change between minor versions should not be too hard to port

Minor version upgrades aren't supposed to be breaking and Haskellers are very good about that, but in the package versioning policy the first two version components (X.Y) are considered the major version, while the third component (Z in X.Y.Z) is the minor version, so what you're running into here is a major version upgrade of unliftio. It's pretty common for Haskell packages to stay at 0.x or 1.x forever.

We do keep master branch fairly up-to-date with the Stackage nightly snapshots (and we're very happy to accept PRs to do so), and especially before releases we make sure to it's compatible with the latest, but releases are fairly infrequent and we don't make a new release for every breaking change in a dependency. The master branch can be pretty unstable at times, so we very much prefer that distro packages never be built from it (we had trouble with that recently, where the Arch version of Stack built from master had major bugs).

We also make some effort to also keep our stable branch compatible, but if the changes to an upstream package end up being too disruptive we'll give up and have to wait for the next release from master.

[felixonmars]

@Blaisorblade Most of the time I submit the patch to upstream and run test suite when there is one.

@borsboom I see, I'll avoid building from master from now on. Last time when I bumped to a git master version was because of the major GHC update, and I should contact upstream before doing that.

But I am not aware of the major bugs you mentioned. Just in case it was the libtinfo issue - that is not caused by updating the stack package, but a change in the ncurses package that affects stack.

[borsboom]

I don't have the issue handy, but it was to do with the fact that master had just had major rearchitecting of snapshots which hadn't been thoroughly tested in the real world yet.

[felixonmars]

I just bumped the stack package to the release candidate (1.6.0.20171202) with the patch from #3626. Sorry for the trouble caused, and I'll try to stick to stable.

[Blaisorblade]

run test suite when there is one

That’s good to hear! Do you include Stack’s integration-tests? That might require a bit more effort IIRC, stack test won’t do it by default. And I’m not sure our test suite has complete coverage — we do extra validation before releases.

Anyway, thanks for the positive response and cooperation :-)

[felixonmars]

Do you include Stack’s integration-tests?

Not yet, but I'll try later :)

[borsboom]

Closing since #3626 merged.

[ip1981]

Please build Stack with the stack.yaml provided in this repository, not with an arbitrary set of dependencies. There have been a number of bug reports that have been difficult to track down due to random versions of Stack (straight off of master) and arbitrary dependencies making it into Arch. It's all but impossible to diagnose problems when we don't know what versions of dependencies have been used.

Guys, your src/Stack/Prelude.hs implicitly imports a lot of stuff. This is the root cause for all these troubles. IMHO.

[Blaisorblade]

@ip1981 I’m afraid opinions without supporting arguments are not so helpful. How would making the imports explicit help? Compile errors are easy to fix. Behavior changes are the real issue, and it’s not clear why making import explicits will make any difference there.