[z3-five] RFC: The future of Products.Five

[Philipp von Weitershausen]

Problem
-------

A lot of us are trying to backport or create additional Zope 3-related 
technology in Zope 2. Whit Morriss, for instance, needs integer IDs in 
Five, the Plone project is heavily using local components now and will 
sooner or later need a more sophisticated site manager implementation 
than PersistentComponents. There's also the need for customizing global 
template-based views ("Customerize" button), something that doesn't even 
exist in Zope 3 yet.

I don't think all of these things should go into the Products.Five 
anymore, for several reasons:

* We're trying to get away from writing products and into writing Python 
packages that can e.g. be installed as eggs.

* Some of these things are not essential to bringing Zope 3 technology 
into Zope 2 (e.g. like the intid stuff), so it may be questionable 
whether it should ship with Zope 2/Five out of the box.

* Starting with Zope 2.10, Products.Five is actually getting smaller 
which is a trend I would like to continue to see. And if I manage to 
land my Acquisition refactoring in 2.11, Products.Five will pretty soon 
decrease in size tremendously, and there are also other things in 
Products.Five that should really be in Zope 2 proper (e.g. OFS).


Proposal
--------

So, what I'm proposing is to feature-freeze the Products.Five package 
and just basically keep making it work for future Zope versions. Five 
1.6 (current trunk) will work for Zope 2.11 (current trunk), Five 1.7 
for 2.12, etc. So, essentially there won't be Five feature releases in 
between anymore, which means we can put Products.Five into the 
Zope/lib/python/Products proper.

New stuff will be added in standard Python packages that may or may not 
ship with Zope 2, Plone or whoever needs them. I personally almost don't 
care, it's really only about defining the right egg dependencies in 
Plone 3.0 or Zope 2.11, I would assume (see also 'Risks' below). This 
seems like the release manager's job who would include stuff based on 
requests from the community and package maintainer's recommendations.

The namespace for these packages should probably be 'five', as we 
already have five.intid and five.customerize and we are, after all, the 
Five project.


Advantages
----------

* We'll be able to use stuff we get for Python packages for free, such 
as installation via eggs, Cheeseshop presence and much less majyck for 
initialization.

* Stuff that we create as part of the Five project does not necessarily 
have to end up in Zope 2. Currently, stuff added to Products.Five 
eventually always ends up in some Zope 2 release which means we'll have 
to maintain it forever, no matter how crappy it turns out to be (e.g. 
Products.Five.site).

* Development of certain components can move much faster than even Five. 
New things like five.intid or five.customerize can be experimented with 
and already be in the right place if they turn out to be stable. If not, 
they won't harm Products.Five, either. Individual packages rather than 
one big one also reduces the amount of work that has to be done by the 
Five release manager (IOW my work ;)).


Risks
-----

* If five.* packages need ZCML config (and I know some will), they will 
either have to be included the Zope 3 way (site.zcml or package-includes 
slug in your instance's 'etc' directory), or we need to come up with an 
approach that Zope 2 people are more comfortable with. I think an egg 
entry point would be a compelling solution. There are plans to do this 
in Zope 3 even so that you can provide configuration from Python instead 
of ZCML. I expect this to land in Zope 3.4 which means we should be able 
to take advantage of it in 2.11.

* It is unclear to me at this point what Zope 2's egg story will be. I 
*hope* that 2.11 will get the same egg story as the Zope 3.4 that ships 
with it does, though noone has talked about eggifying Zope 2 yet. We 
should probably do that.


Comments welcome :)