The fact that GHC needs to have its own containers shouldn't prevent a consistent package set from using a different one. The only hypothetical problem would be if the GHC API leaked containers types, but I'm pretty sure it doesn't: they're all wrapped up in newtypes and exported abstractly, unless someone's made a mistake.

On Apr 1, 2017 6:09 PM, "Sven Panne" <svenpanne@gmail.com> wrote:

2017-04-01 20:53 GMT+02:00 David Feuer <david.feuer@gmail.com>:

It's come to my attention that Stackage doesn't have the latest and greatest versions of containers. Stackage nightly is on 0.5.7.1, and I just released 0.5.10.2. It'd be nice to get that fixed, but the containers maintainers do not have the time to take responsibility for Stackage curation. Could whoever's responsible please take care of it?

If I see this correctly, there is nothing to take care of: Stackage nightly and LTS both ship GHC 8.0.2, and that contains containers 0.5.7.1. When a new GHC is released and that ships with a new version of containers, it will be on Stackage. Apart from that, there is nothing you can do: Stackage is there to have a consistent set of packages, so containers is not even in https://github.com/fpco/stackage/blob/master/build-constraints.yaml, because it ships with GHC.

That's at least my understanding...

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.