Brian Sutherland wrote:
On Fri, May 11, 2007 at 11:59:37PM +0100, Martin Aspeli wrote:
 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.

I'm not saying "don't do it", but more "don't try do it by hand" or
you'll burn out your release manager.

A meta egg that only specifies a few dependencies is managable by hand,
but a meta egg that exactly specifies over 100 packages and exact
versions is not.

If we are capable of managing a release of 100 packages now, and not in the future with eggs, that sounds like a step backwards for me.

I think (to me!) a large part of the appeal of Zope3 is that it is a cohesive, well-tested, well-QA'd collection of libraries which solve an aweful lots of needs. If we devolve it all into little bits that live and die on their own, that may make life simpler for the now-possibly-out-of-a-job release manager, but the sum of the parts will be less than the current hole since undoubtedly some bits will stop playing so nicely together.

I don't think this is the desire, though. What I'm advocating, is a careful definition of "the core", which is subject to synchronised release management, buildbots, eagle-eyed release managers and all the rest. Some things may then spin off outside the core, or into concentric layers of functionality managed by different sub-communities.

But for the *user* of the library, there has to be a way to get a "known good" stable version, which promises some migration path when things change in the future.

But I do think that a hand-managed super meta-package is a very
difficult thing to do.

I don't really care about the mechanism. You may well be right. But we need something. :)

Add a meta egg with a few non-versioned dependencies to the above
collection of eggs and it becomes a release (or multiple releases) :)
Anyone, as long as they only download eggs from that URL, it guaranteed
a set of eggs that works well together.

So long as someone makes sure the meta-egg keeps working. Eggs with non-specific versions are scary, since a new version could be automatically downloaded and break everything. It requires control and consideration at some level.

Bugfixes are simple, simply drop an egg in that directory.

One very bad thing about such a URL is that it makes it very tempting
for developers to upload forked versions of things like twisted, pytz or
mechanize there.

However, buildout's approach of "saving" a known good dependency tree is
also reasonable:

Though I'm not sure how well it will deal with bugfix releases or
allowing others to extend a release you make (i.e. plone on top of

Plone is a good example, since, via Zope 2.10+ it is a consumer of Zope 3's libraries, but not its app server.

I'd like to be able to say "my package requires the core of Zope, version 3.3". That may imply a few packages I don't actually use, but so what?

Perhaps even buildout can become the method to create a directory of
eggs/tarballs that will be a "release".

We've thought about using buildout to create installers and tarballs for releases in Plone. Not sure what state that thinking is in.

I'm sure both the "repository" and "saved" release types can be tested
together automatically using buildout.

One advantage of a lower level construct such as a meta-egg (or just a list of eggs withs specific versions?) is that it can be used more easily in a non-buildout environment.


Zope3-dev mailing list

Reply via email to