On 19 Apr 2008, at 22:39 , Chris McDonough wrote:
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 single egg.
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 forth.
Ok, fine by me.
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.
Which they're not :).
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.
Well, taking your "everything that used to be in the tarball..."
argument, then this would indeed be the outmost egg, incl. the
instance scripts.
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 whole path.
I have a slight preference for "Zope2" because that's what egg names
usually look like. Also, if you told people Zope 2 was now available
in egg form and asked them to guess what the egg was called, I think
most would come up with "Zope2".
_______________________________________________
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
