[Zope-dev] Re: RFC: The future of Products.Five(green eggs and zope)

[whit]

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