I can no longer maintain containers
Carter Schonwald
carter.schonwald at gmail.com
Mon Apr 4 02:30:21 UTC 2016
agreed, containers needs some careful custodianship because of its
inclusion in ghc's shipping library set, and the extent to which its used
across all known haskell code bases
On Sun, Apr 3, 2016 at 10:28 PM, Phil Ruffwind <rf at rufflewind.com> wrote:
> Correct me if I'm wrong: my understanding of how Cabal currently works is
> that if containers becomes a meta-package for other packages (say,
> containers-map and containers-seq), then users of the package would have to
> explicitly specify containers-map and containers-seq in the .cabal file.
> Additionally, to provide compatibility with older versions, there would
> need to be some sort of conditional logic too. This wouldn't be easy to
> automate, since one also needs to convert the version bound for containers
> into corresponding version bounds for the subpackages.
>
> Hence, I think unless there is a way to make it 100% compatible with
> downstream splitting the package is probably not a good idea, given that containers
> is such a fundamental package in the ecosystem. Looking at
> http://packdeps.haskellers.com/reverse , there are about 3000 packages
> downstream that depend on it (one of highest among the list).
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160403/3f2084de/attachment.html>
More information about the Libraries
mailing list