Philipp von Weitershausen wrote: <snip />

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).

+1 to this logic

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.

+1

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).

flipped around, it would be nice to see the crufty features in Five moved out to their own packages, to enable BBB *if needed*. this is similar to nuxeo's XYZonFive product pattern, but easy_install-able.

* 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 ;)).

would like to note that other packages in Zope2 also need this ability to release asynchronously from Zope2's schedule; ZopeTestCase in particular comes to mind(Testing should be a namespace package imho).

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.

big +1 here. would love to use paste deploy to configure my zope instance. 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.

I will defer to other's here but say this: I'd rather have better tools to configure with than more options in the configuration language.

* 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.

re zope2 egg story: some talk has occurred thanks to goldegg and general irritation suffered by myself, rocky, nouri and others. Tres and McDonc have definitely plumbed the ugly depths of zope2 thinking about this problem for goldegg. Nouri has run the plone stack as an egg; I've run Zope2 as an egg. re my experience, I made a somewhat indecipherable post about my experiences with easy_install-ing zope from svn with workingenv. To reiterate, the results are pretty cool: all of zope is installed into your workingenv/lib/python, all your scripts(repozo, mkinstance, etc) are installed into your workingenv/bin . Some minor edits are required to make the scripts find the proper libs(due to SOFTWARE_HOME path expectations) and the site skeleton disappear but really, it's darn close to working as an egg. workingenv takes care of the nasty "where should my zope stuff go in relation to the real python world" question. it's likely that you could use setup_tools prefixing to run multiple different versions of zope in the same env; or just simply make a 2.10 env for your 2.10 instance. this means that the "egg story" really doesn't have to happen inside zope(except for wort removal on the Zope2 package). It can just use a well thought out existing python egg story: workingenv(see http://bfhammer.blogspot.com/2006/09/bootstrapenvironment.html for more info). Perhaps if we want to spruce it up a bit, zopectl could handle workingenv's "source bin/activate" and maybe alias the command "install" to the workingenv's easy_install from the zopectl prompt. The distribution could just be a small setup script for zopectl w/ a workingenv recipe that sets up the equivalent of the software home. We still have to handle the Products issue for add ons(mcdonc, donde estamos con Basketos?). But if Basket is added to 2.11, this might not be such a big deal. this probably more of a separate proposal on "what should the Zope2 egg story be?" so if you have feeling, reply as such. -w