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

On Tue, Jan 14, 2014 at 12:01 PM, Roman Cheplyaka <roma@ro-che.info> wrote:

* Ryan Newton <rrnewton@gmail.com> [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.

Regards,
Reid Barton