On 04/06/2016 10:40 PM, Milan Straka wrote:
Hi all,
personally I think that splitting containers has nearly no advantages, but may negatively affect many users, so I am against it. The details follow.
It is true that containers consists of unrelated data structures, but many data structure libraries do, and I do not believe that is should be a reason to split the package. Also I feel that containers are quite small.
From the user point of view, I doubt people would appreciate having more fine-grained versioning of parts of containers. Also note that it is difficult to use other version of containers than the one bundled with GHC (hm, template-haskell used to depend on bundled containers, but at least in 7.10 it does not anymore -- only Cabal, binary, ghc, haskeline, hoopl and hpc does; the situation is better that it used to), so incremental releases of containers between GHC releases have (had?) little use.
From the maintainer point of view, I think building/testing of containers is fine, as the library is pretty small and (at least from my point of view) builds reasonably fast. Moreover, as containers are _widely_ used, I believe we should make as little backward incompatible changes as possible, so bundling releases with GHC releases is fine (and therefore little would be gained from having three smaller packages).
Splitting the package may cause problems -- some people think so, some think that the problems are recoverable -- but still, it is probable that some issues will appear and these may affect a lot of users.
+1 (FWIW, personally a split wouldn't bother me, but then I only have a few packages on Hackage.) Given that "containers" already has a huge number of revdeps, the decision to split can always be revisited at a later time without much extra cost. (I mean, if $THE_WHOLE_WORLD_2016 depends on containers now, it's probably not *that* much more effort to split if $THE_WHOLE_WORLD_2018 depends on it. I'm assuming that *some* sort of compatibility shim/package would have to be provided regardless.) Regards,