Releasing containers 0.5.3.2 -- before GHC 7.8?

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


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

> On Tue, Jan 14, 2014 at 12:01 PM, Roman Cheplyaka <roma at ro-che.info>wrote:
>
>> * Ryan Newton <rrnewton at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140114/370ce00a/attachment.html>


More information about the ghc-devs mailing list