ok, thats a good point
On Tue, Jan 14, 2014 at 3:15 PM, Reid Barton <rwbar...@gmail.com> wrote: > 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 > >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
