Nice graphs! I was thinking the same thing (but of course, wouldn't have gotten around to actually doing it).
I think code reuse is generally a good thing. As long as there is no circular dependency, what's wrong with depending on a few eggs? It's better than rewriting the parts you need, right? (and if your few dependencies each depend on few more, pretty soon it's a lot of eggs. Oh well.) But it's important for popular eggs to be kept in a working state, and not change existing APIs in them when avoidable. Another way to look at it, is that depending on an egg when you only need 10% of its functionality is a waste of memory. So then you'd want to have smaller eggs (and more of them), which tends to increase the dependency "problem". It's no different than what is happening with Gentoo... several times I've had stuff be temporarily broken because a dependency won't compile, or won't compile when I turn on a config option that I'd really like to have turned on. It's not a nice experience when that happens, but is sometimes unavoidable due to the philosophy of the distro (always the latest stuff and you compile everything). As with Linux distros, one way around it is to have binary releases periodically, in which everything is guaranteed to work together properly (because it's all been pre-compiled and tested). If Chicken plus a bunch of eggs got included in Debian or Cygwin, that would be happening (or is it already?) So far Chicken is more like Gentoo than it is like Debian. Like I just upgraded libexpat (because I was installing the expat egg, and without thinking about it too much I figured I ought to use the latest 2.x expat rather than 1.95 or whatever it was). That ended up requiring upgrades and recompiles of nearly everything on my Gentoo system, because they changed the library name from libexpat.so.0 to libexpat.so.1. I'm still not done recompiling everything, and had to switch to WindowMaker for a while because KDE takes forever to compile. It's annoying, but what would you say, that it's wrong for so many packages to use expat? They should all write their own XML parsers? or include their own copies of expat in their own source trees? (like SlimServer does with a lot of dependencies... I find that annoying) But now that expat is so popular it obviously cannot have quick and/or revolutionary API changes. If it ain't broke, fixing it will be a very unpopular choice (and the fact that it's popular pretty much means by definition that it ain't broke). That will tend to happen with a lot of eggs too. Maybe staged releases will become important... make a clear distinction between the stable version of an egg and the new/improved/under-development version. When one egg depends on an older version of another (and will not work with a newer version) maybe there should be a way to specify that in the metadata, so that installing the one egg can automatically install the older version of the other. (Or can they even co-exist?) Gentoo's portage system can do stuff like that. On 22 Aug 2007 22:14:23 -0300, Mario Domenech Goulart <[EMAIL PROTECTED]> wrote: > http://g3pd.ucpel.tche.br/~mario/egg-deps/ _______________________________________________ Chicken-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/chicken-users
