Philipp von Weitershausen wrote:
Jim Fulton wrote:
We need to stitch zope.app into Zope 2 more carefully than we
are now. Much of what we are stitching is unreleased in Zope3
and depends on things not stitched nto Zope 2.
Among other things, this means that we can't use
python2.4 test.py -m.
to run all tests without getting test failures.
It would be great if someone would sort this out before
we do any Zope 2.9 releases. :)
Well, from that vague "we need to do it more carefully" I deduce that
you would like to stitch in zope.app like we stitch in zope, i.e. each
Yup -- well, maybe not. See my rambling though exercise below. :)
> Unfortunately, that will not work equally well
because there are several text files at zope.app, more than just the
At least the Python modules and zpkgutils files will be needed in Zope 2
as well. The real problem is that svn:externals doesn't work on files,
just on directories. So, we'd have to manage separate copies of those
files. Are you sure we want to get into that?
Yes. In the next release cycle, I want to take another look at zope.app.
In particular, I think it's time, within the Zope 3 project to revisit the
concept of "core" and drastically reduce the size of zope.app by moving things
out. This will have one of 2 possible outcomes for Zope 2:
- Zope 2 will no longer need to stitch zope.app at all. Everything it needs
will be available in individual zope packages, or
- zope.app will become small and have only what is needed and Zope 2 will
be able to stitch all of it.
I'm not sure which it will be, but I suspect the former.
In the mean time, meaning for Zope 2.9 only, I think we should just
copy the files we need, possibly editing them.
Also, in selecting which subpackages from app to include, I suggest
starting with what was included in X3.0. Even this might prove to be
painful because of our decision to use optional subpackages.
For example, many packages have subpackages that provide optional features
like index or fssync integration. This means that Zope 2 can't get these
via externals without also getting the optional bits. Personally, I don't
like optional subpackages and would rather have a much shallower and broader
Another option would be to stop using externals and switch to a "build-out"
model. With a build-out model, you don't rely on a simple checkout to
get you all you need. Rather, you run a program of some kind that gets
you what you need. This has the advantage that the program can have logic
to adjust what you get according to special needs. For example, we are
in the process of contributing a build-out framework that Benji built
for us here at zc:
Unfortunately, this is lacking docs and tests. :(
Alternatively, we could, for Zope 2, as we have for Zope 3,
abandon the assumption that everything in the repository is
included in the release. I guess now that we are using zpkg,
we can arrange that the Zope 2 release includes only stuff in
zope and zope.app that we want. In fact, we can probably just reuse
the release information from Zope 3.2.
OK, so, if we are going to use zpkg to make the release -- and this
raises a number of issues too, which I'll brong up in a separate note --
then we can separate repository management from release management and
use zpkg facilities to control what we get. In this case, we should
really stitch more of Zope 3 into the Zope 2 repository until we
get to the point that all of the zope.app tests pass, and we can stitch
all of zope.app as we are doing now.
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -