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
However, buildout's approach of "saving" a known good dependency tree is
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
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