[Zope-dev] Re: zope.app stitching

[Jim Fulton]

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 at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org