On 7 Jun 2007, at 08:45 , Andreas Jung wrote:
--On 6. Juni 2007 18:01:27 +0200 Philipp von Weitershausen <[EMAIL PROTECTED]> wrote:


At the PIKTipi sprint this past weekend, Andi Zeidler, Andreas Jung and I worked on integrating ZODB 3.8 and Zope 3.4 into the Zope 2 trunk. Zope
3.4 has actually "exploded" into many eggs that are now independently
managed and released. I therefore looked into a way to make Zope 2
dependent on these eggs instead of shipping with its own copies of the
packages. There are clear benefits to that:


First, eggs are cool and the ongoing eggification is a good thing. However making such major changes for the next release I would like to discuss a few things or get answers.

With my email I might've given the wrong impression that I'm going to eggify Zope 2 and that that the Zope 2 release as we know it won't exist. That's not the case. My playground is, in fact, in a separate top-level project called "Zope2.buildout" that simply points externals to the "Zope2" project. "Zope2.buildout" is an experiment (deploying Zope 2 from eggs).

I would like to discuss eggification and future releases of Zope 2 separately because I haven't fully worked out all the issues myself yet. My email purely concerns *one* problem (see the subject line) that is related to eggification: shipping with a standard docutils package. Eggs or not, I think being able to ship with an unmodified docutils has advantages (no more having to do vendor imports and applying the patches ourselves).


What will be the impacts on the source code distribution?

None. We can continue making tarballs that contain everything like we do now. I'm not saying we should (I haven't fully made up my mind), but it's certainly possible.

The Zope2 egg only contains what is Zope 2, the rest is pulled in as dependencies. In the end you end up with the same amount of code, it's just coupled differently.

How would you
install "Zope from the sources" (especially if we don't include the 3rd-party eggs like docutils)?

Again, the standard tarball install with configure; make; make installd doesn't have to go away.

As far as the egg is concerned, you install it like you install every egg-based package "from the sources": download the tarball and do python setup.py install.

Working with eggs in a Zope environment requires that the eggs must be installed isolated within the softwarehome. We can't install Zope eggs within the Python environment (because it causes already a bunch of pain right now). Something like a buildout or workingenv environment would be necessary....also with a Zope-local installation of setuptools/easy_install!?

Sure, but that's not a Zope 2-specific problem. Which is why tools like buildout and workingenv exist. So I see no problem here.

Do we really want to encourage the end-user to update parts of the Zope core or the 3rd-party packages individually?

If it's not part of the Zope2 egg, then it's replaceable. I think that has advantages and can be a good thing. In the past people wanted to backport certain features that occurred in a later version of Zope 3 to an earlier version of Zope 2. Well, now they don't have to backport, they can just use a newer version of that particular package they're interested in.

As far as 3rd party packages are concerned, it makes even more sense. pytz is a good example. Every so often, some country decides to change their timezone. Software running on old pytz releases (which were coupled to Zope releases) are stuck with old data. With eggs you're able to just upgrade pytz.

I am skeptical about this because we always shipped Zope as a collection of tested and trusted components.

We can still do that, egg-based or not, and attach a sticker "Warranty void if eggs are exchanged".

Of course you could also updated package in the past manually however by using eggs we are lowering the barrier for a end-user to mess up his system. However I always see the advantages of the approach to bring updated or fixed packages much easier to the Zope user.

Before stepping forward with your work (on the Zope trunk) I would like to
get the "big picture" first.

Again, I'm not doing any changes to the Zope trunk, except the one thing I clearly laid out and proposed: being able to ship with a standard docutils package.



_______________________________________________
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 )

Reply via email to