Fwd: [Haskell-cafe] Data.Tree.Zipper in the standard libraries

[Johan Tibell]

On Tue, Jun 3, 2008 at 10:58 AM, Neil Mitchell <ndmitchell at gmail.com> wrote:
> Hi
>
>> Well if this is the common agreement then I will withdraw my proposal.
>> Maintaining a single module package floating around is too much effort
>> for me. I prefer to keep a local copy in the projects that need it
>> instead of maintaining an extra dependencies and to force the users to
>> download extra software. I am sorry for the wasted time and effort.
>
> I think that's a real shame. Maintaining a cabal package is relatively
> little effort. I have several packages which are just one module long
> (see for example Safe - which is not only one module, but every
> definition within it is only one line!). With cabal-install, the extra
> effort to install dependencies is literally nothing - its all handled
> automatically. And once you've got some users, and some varied
> experience of using the library, then I think making a library
> proposal would be a good idea.

I looked through all packages published by you on Hackage (quite a
few!) and all of them expect yhccore, proplang, GuiHaskell and
firstify depend only on core packages (e.g. base, containers, mtl,
etc.). None of the libraries depend on many small non-core package and
at least one depends on big packages like gtk. In my experience
maintaining all these "fine grained" packages with no or few
dependencies is not that difficult. However, maintaining packages with
many small dependencies is.

In my opinion packages should be on a more coarse grained level than
modules. Maybe one per task e.g. gtk for graphics, urllib for client
side HTTP, etc. It's also the granularity that is used in other, more
powerful packaging managers for Linux.

Cheers,

Johan