[Haskell-cafe] a poorly thought out suggestion for cabal and packages that have lots of instances

[Marc Weber]

Excerpts from Ivan Miljenovic's message of Tue Mar 16 01:53:13 +0100 2010:
> On 16 March 2010 11:50, Marc Weber <marco-oweber at gmx.de> wrote:
> > I may be mistaken - but can't you just put the instance in a module
> > (within syb-with-class) and make syb-with-class not import it by
> > default?
> 
> That would still require syb-with-class to depend upon Text, etc.,
> which is probably not a good thing to do.
Doh. I've missed it.

Sure. I think MissingH has similar trouble: You only want to use
one or two features - but you have to install all dependencies.

Three choices:

a) add dependencies to syb-with-class.
  You could even think about refactoring text and split it into
  text-types and text-implementation.

  This way adding a dependency isn't such a big change.

  But it still is bad because syb-with-class maintainers in general 
  don't want to align their changes with text updates. Neither do they
  want to fix problems arising from changes in all those packages it
  should provide instances for. Usually maintainers ask for splitting
  off such code. (vim backend for Scion is one case ..)

  On the other hand the Firebug people chose to align releases of core
  Firebug plugins to enhance stability and user experience.

  Anyway this is what some packages do. Eg Vim *does* contain many gui
  backends. You can't download a vim-common shared library and install
  vim-gui-gtk vim-gui-... There would be too many combinations.
  Package maintainers have stripped them down to
  vim-tiny
  vim-gui-with-X-huge-features
  ... or similar.
  But it's easy in this case - no (?) application depends on Vim.

b) using conditional compilation
  usually package writers writing package descriptions for distributions
  such as gentoo, Debian just compile all backends. I think Debian
  always enables both: gnome and kde.
  Adding use flags to gentoo for each feature would be overkill.

  So in the end this is equal to a) (IMHO)

  I can not even estimate the amount of work it requires to make
  packaging tools cope with conditional compilation. You have to start
  propagating features to base packages etc.

  I think ivy claims to solve this kind of issue partially. (I don't
  know it that well)

c) add many additional packages
  > The problem is that it seems like this might really clutter up hackage?
  The way to go is improving tools (Hackage, IDEs, cabal-install) to
  cope with this situation.
  
  I'd even propose renaming the extra package to
  syb-with-class-text-instances. Then everybody can see what it
  contains.
  
  tools such as cabal-install will have more trouble to find a solution
  because there are much more possible solutions to take into account.
  
  One way to cope with this is always use latest version and fix broken
  packages..

Last but not least it is also a marketing issue:
Eg OpenERP vs Adempiere: OpenERP is said to have *many* plugins. But
some of them just add some DB fields or make a field have more
characters. Adempiere contributors tend to call this a "localization" of
their software. (You can read this up on their sf forums :) )
But I don't think anybody really cares whether we have 3000 or 5000
packages on hackage. In the end we all care about getting things done.
Installing 20 packages and running cabal 20 times more often does
matter.

So what is correct? I don't know.

Marc Weber