[Zope3-dev] Packaging

[Martijn Faassen]

Jim Fulton wrote:
> I'd like us to think about Zope 3 packaging a bit.
> 
> Some initial thoughts on packaging:
> 
> - zopeproducts was a stupid idea of mine that I'd
>   like to abandon.  There's no point in providing a special
>   top-level package (TLP) for Zope 3 add-on products.  Most
>   independent Zope 3 add-on products should be either in
>   their own TLPs or should be organized into project-defined
>   TLPs.

And probably should be in a style like:

infrae.silva

or:

plone.plonecore

or for that matter:

silva.silvacore 

:)
 
i.e. prefixed with project name/companay name.

This is only a guideline of course, but will make namespace clashes a lot
less likely.

> - I want to make zope.app much smaller.  zope.app should contain
>   core infrastructure needed by the Zope application and not much more.

Of course what is needed by the Zope application is determined by the
Zope application. So what's core infrastructure could be a trifle hard
to define. :) 
 
Anyway, agreed that zope.app should be smaller. We could prepare a list of
what is zope.app and what should leave.

> - I'd like to make it easier for add-on products to survive refactoring.
>   We have an area in the repository now, zopeproducts, containing products
>   that are mostly dead because they weren't refactored when Zope was
>   refactored. This is a dang shame.
> 
>   I'd like to introduce a new package, zope.products, that is a container
>   package for add-on packages for the zope application (zope.app) that are
>   part of the zope project.  These add-on products:
> 
>   - Are in some sense "standard".  They may provide widely-used components
>     (e.g. common content types) or they might provide examples used to
>     document or teach.

To me that means that zope.app will become almost completely empty of
any content-space objects besides containers and some semi-software 
content space components like ZPT Page and the like. Any real
specific content-management related objects would leave for zope.products.

A set of specific content-management related objects may be essential
for demo/example/marketing purposes, so there *should* be a package in
zope.products for this.

There's a risk that a half-baked set of CMS objects in zope.products will
by default become "the successor to CMF" or something like that. What happens
if people start building on it? This suggests that the 'widely used
components' use case should be physically separated from the 'examples
used to document or teach' use case. See my zope.examples proposal below.

[I'm fine with a set of *non* half baked CMS content objects becoming
important, of course.]

>   - Do not require special software.  Anybody who can install Zope can run
>     these packages without any additional software. This excludes most 
>     database interfaces, for example.

A nice guideline. Perhaps an analogy with the Python interpreter distribution
would be useful:

interpreter - zope
builtin objects, functions - zope.app
standard library - zope.products
Demo - zope.examples?
Tools - utilities 

What this brief analysis suggests again is that we need zope.examples, separate
from zope.products. This will reduce the risk of people building on
example code, makes it clear what is *only* example code and what code
is intended to be used in production, etc. Of course all production code
can always serve as example code, but the other way around is not the case,
and that's why there's a good case for zope.examples.

>   - Will be refactored when Zope is refactored.
> 
>     This means that these products must have adequate unit and/or functional
>     tests. These tests must be understandable, so that people doing 
>     refactoring
>     have a prayer of getting failing tests running without pulling their 
>     hare out.

Again very similar to what happens to the Python standard library. If
the Python interpreter changes, the library will be tested and adjusted
where necessary.

>   - Will have identified contacts who are willing to help out by at least
>     answering questions when issues arise during refactoring.

I tried to set up such a system in an as-yet-unaccepted (and likely
never to be accepted limbo state?) PEP for the Python standard library:

http://www.python.org/peps/pep-0002.html

It may contain some useful concepts and guidelines.

>   - May be removed if they become too dificult to maintain or are hudged not
>     to be worth the effort.

As Philipp mentioned in his reply, this will become much harder later on,
so we have to be very careful about what ends up in zope.products.

>   - May or may not be included in Zope distributions.

What does this mean? If zope.products contains widely used objects, then
I'd rather see it introduced in the standard distribution. I can imagine
stripped down Zope 3 distributions for special purposes that wouldn't
include zope.products, but that'd be unusual, just like a stripped down
Python standard library is the unusual way to distribute it.

Perhaps there's a difference between development platform distribution
(zope.products always included) and production platform distribution
(may be 'frozen' so that not all of zope.products is included).

> Thoughts? Suggestions?

One more observation, no conclusion attached:

zope.products breaks the rule that nothing in zope should depend on
zope.app. In that sense the original 'zopeproducts' name is better. It
also is more similar to what any non-zope committer extender can do when
extending Zope: they don't have the ability to add a new package into the 
'zope' namespace; they can only add new python packages.

Regards,

Martijn