I can no longer maintain containers

[Erik Hesselink]

I also hope splitting containers would not be done lightly. Recently
network-uri was split out of network, and even though people thought
very hard about this, there were problems, and people had to change
their cabal files. I don't really see the advantages as very big (you
can have multiple maintainers on a single package, the build times
aren't that long and generally you don't build it often anyway, and
I'd say the theme is "containers" :)) and like others have said, any
small breakage will affect lots of packages. So please carefully
consider if the advantages outweigh the risks before taking this
action.

There are other costs to splitting up packages; it is not free. Cabal
dependency resolution will be slower, you'll have to add more things
to your cabal file, stack.yaml, etc. We don't want to end up in the
node.js situation with single function packages.

Erik

On 8 April 2016 at 09:10, David Feuer <david.feuer at gmail.com> wrote:
> Just to be clear: no one is looking to make major breaking changes to
> containers. If it is split, it will have to be done in such a way that
> people depending on it won't even notice, except by watching Cabal build
> messages flash by. If that's not currently possible, then I don't think
> *anyone* would want to split it now.
>
> On Apr 8, 2016 3:05 AM, "Sven Panne" <svenpanne at gmail.com> wrote:
>>
>> Just to add my 2c to the "to split or not to split" topic: Please do not
>> split such a fundamental package! As already mentioned, it is the 2nd most
>> used package on Hackage (only slightly behind "bytestring" and ignoring
>> "base"). Even making tiny incompatible changes will immediately break
>> hundreds, if not thousands of packages on Hackage. If this is really
>> planned, there should be an extremely good reason for it, and I can't see
>> one: The package is very small and there is almost no activity in the
>> repository (https://github.com/haskell/containers/graphs/commit-activity),
>> so maintenance burden can't be a valid reason for splitting. And even if it
>> one wants to split, there are lots of orthogonal aspects of containers:
>> lazy/strict, order-based/hash-based, set/map/multimap, sorted/unsorted
>> variants, catenable or not, etc. Which of these should be the splitting
>> criterion? The extreme of putting each data structure into its own package
>> seems to be a little bit excessive.
>>
>> OTOH I'm all for adding missing functionality to "containers", at least if
>> they don't introduce incompatible changes.
>>
>> Of course one can add additional packages with subsets of "containers",
>> keeping the latter untouched. If most Hackage authors switch to the new
>> packages, "containers" can be phased out. But even if that happens (which I
>> doubt), this will take quite a few years.
>>
>> Cheers,
>>    S.
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>