Philipp von Weitershausen wrote:
Chris McDonough wrote:
I wonder if Philipp would be amenable to writing a proposal on this,
and get Chris McDonough's input.
IMO, a Zope2 egg release should depend on the following packages:
- 'ZODB3' (already packaged)
- 'transaction' (depended on by newer ZODBs)
- 'ZConfig' (also depended on by newer ZODBs)
- 'StructuredText' (should be broken out into its own egg)
- 'docutils' (should use existing egg)
- 'mechanize' (should use existing egg)
- 'pytz' (should use existing egg)
- all zope.* packages (properly pinned) that zope2 depends on
Yup. These are all done already.
The actual top-level egg that depends on these things would contain
all the other packages depended on by Zope 2 (e.g. DateTime, Missing,
Products/*, Acquisition, ExtensionClass, ZPublisher, ZServer, etc).
Yup, we can do it like that. I still maintain that the zLOG, Interface
and DateTime packages could be packaged separately without much effort.
The benefit with those is that they'll either be obsolete very soon
(zLOG, Interface) or may need off-beat updates (DateTime).
I'd be slightly happier if everything "we" (Zope 2 folks, as opposed to Zope 3
folks, ZODB folks, or other independent authors) maintain shipped inside a
In particular, I think this might be what to aim for in the very first Zope 2
egg-based release, because we can always move stuff out in a later release, but
it's harder to reel something back in if we find that moving it out has been a
mistake. The "one big egg" strategy might also let us explain it a little more
easier to old-hand Zope2 devs who aren't used to eggs: "everything that used to
be in the tarball except ZODB, Zope 3 libraries, and external libs is in the
zope2 egg". Then in a subsequent Zope 2 egg release, we could say "oh, now that
you're used to eggs, we've moved DateTime out into a separate egg", so on and so
But I'll try not to get hung up on it if other really want to bust things apart.
I guess in particular, I'm not keen on trying to externalize ExtensionClass or
Acquisition unless somebody else has a strong desire to do this because they're
using them outside Zope somehow.
We might call it 'zope2libs'.
What's wrong with just 'Zope2'?
It would be nice to disambiguate the libraries needed to run Zope 2 from the
wrapper stuff required to configure an instance. The very outmost "meta-egg"
(or buildout, or whatever) should probably be named Zope2. This might or might
not be it. If this *is* that outermost egg, "Zope2" sounds good to me.
A nit: I might call the outermost egg "zope2" because I have a preference for
lowercase egg names and we also already have a *package* named "Zope2", and it'd
be nice to know where you are at the bash prompt without needing to print the
What needs to get worked out is the ability to share headers between
ZODB and this package so things can compile properly.
I don't see this as a huge problem. You have a point that C headers
introduce un-documented dependencies, but then again, how often do C
headers change? It has worked so far with externals to the ZODB tree,
it's not like anything's going to change there any time soon. (For
instance, when I hacked Acquisition to support __parent__ pointers, I
didn't have to change the headers either).
We can probably manage it by being careful to match up egg dependencies to
externals at release time. If folks force an install that doesn't make sense
dependency-wise, they can lose.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -