[Zope-dev] shipping with standard docutils

[Philipp von Weitershausen]

On 7 Jun 2007, at 08:45 , Andreas Jung wrote:
> --On 6. Juni 2007 18:01:27 +0200 Philipp von Weitershausen  
> <philipp at weitershausen.de> 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.