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

Excerpts from Ivan Miljenovic's message of Tue Mar 16 01:53:13 +0100 2010:

On 16 March 2010 11:50, Marc Weber 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