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