Releasing containers -- before GHC 7.8?

Reid Barton rwbarton at
Tue Jan 14 20:15:32 UTC 2014

On Tue, Jan 14, 2014 at 2:19 PM, Ryan Newton <rrnewton at> wrote:

> On Tue, Jan 14, 2014 at 12:01 PM, Roman Cheplyaka <roma at>wrote:
>> * Ryan Newton <rrnewton at> [2014-01-14 11:41:48-0500]
>> > Replacing containers seems like a real pain for end users
>> Is it a real pain? Why?
> One thing I ran into is that cabal sandboxes want consistent dependencies.
>  And when users get to this point where they need to grab our latest
> containers, they've got a bunch of core/haskell platform packages that
> depend on the old containers.
> I didn't mean that there was anything difficult about containers itself,
> just that almost everything else depends on it.

In addition to the general pain of updating packages at the base of the
dependency hierarchy, there is also the fact that the template-haskell
package depends on containers. As far as I know upgrading template-haskell
is impossible, or at least a Very Bad Idea, so any library that wants to
use an updated version of containers can't use template-haskell, or even be
linked into an application that uses template-haskell directly or through
another library.

As far as I am concerned as a GHC user, versions of containers that aren't
the one that came with my GHC might as well not exist. For example if I see
that a package has a constraint "containers >= 0.10", I just assume I
cannot use the library with GHC 7.4. Thus I'm strongly in favor of
synchronizing containers releases with releases of GHC.

Reid Barton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list