[Zope3-dev] Re: what dependency to use for "zope 3"

[Martin Aspeli]

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:
> 
> http://svn.zope.org/zc.buildout/trunk/specifications/repeatable.txt?view=auto
> 
> 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
> zope3).

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.

Martin