Brian Sutherland wrote:

It's just going to get very difficult very quickly to manage such a meta
egg with over 100 or so dependencies. Though I guess there'll be
automated tools to manage this.

Better we do the difficult part than each and every user does it. In the ideal world, there are no version conflicts. In the real world, there will be subtle version conflicts that mean that you can't just always get the latest release of each egg. Anyone who's used something like Gentoo Linux, with frequent and unsynchronized releases of different products know what happens when two packages require different version of the same library, or some automatically updated package suddenly remove the little bit of the API you were depending on.

Put differently, you may know that you need zope.annotation and, but I suspect that most people won't quite know where to start, and won't quite know what's available to them. If they start with some particular dependency and start exploring the dependency graph, they'll probably miss something that's either standalone or on a completely separate dependency subtree to the one they're on.

I think another alternative is to separate the releases into different
"repositories", kinda like "All zope 3.0.0 eggs are at";.

Having eggs doesn't absolve us from doing release management. :) We still need to take some of the pain of testing and making sure there are adequate tests and making sure things work well together. It's part of the QA process (which Zope 3 has done immensely well to date, in my opinion). If that overall responsibility eventually falls on no-one, then I fear we'll lose the great integration power we have in Zope 3 at the moment.

Most people just want a "known good" that they can depend on, where they know that changes are going to be limited to important bug fixes. They don't care if they get ten extra packages, what's a few megabytes of disk space.

It's all well and good (great, even) that people can specify their own dependency subtrees (I need the annotation and component parts of Zope, I don't want the rest), not at least because it gives entirely different platforms a better chance of re-using our code, but someone still needs to look after the whole. There are too many packages to have independent maintainers who each (a) are available to do timely releases (b) don't forget to make release after a while and (c) are able to test that the code that is supposed to work with other things, continues to work with those things.


Zope3-dev mailing list

Reply via email to