On Tue, Jan 14, 2014 at 2:19 PM, Ryan Newton <rrnew...@gmail.com> wrote:
> On Tue, Jan 14, 2014 at 12:01 PM, Roman Cheplyaka <r...@ro-che.info>wrote: > >> * Ryan Newton <rrnew...@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
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs