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 package individually.
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 __init__.py:
DEPENDENCIES.cfg PACKAGE.cfg PUBLICATION.cfg browser.zcml configure.zcml content_types.py datetimeutils.py decorator.py ftesting.zcml menus.zcml meta.zcml servicenames.py timezones.py
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 package structure. 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: http://svn.zope.org/Sandbox/zc/buildout/trunk/ 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 -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org