[Haskell-cafe] a poorly thought out suggestion for cabal and
packages that have lots of instances
marco-oweber at gmx.de
Mon Mar 15 21:58:12 EDT 2010
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.
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
... 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
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
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
So what is correct? I don't know.
More information about the Haskell-Cafe