Dieter Maurer wrote:
Whit ("mailto:[EMAIL PROTECTED]") reported that "AdvancedQuery"
is going to ship with Plone3 and that packaging would be easier for them if
"AdvancedQuery" were part of the Zope 2 distribution.

I fail to find an explanation *why* that is.

According to Whit, Alexander Limi seems to be interested to have
"Managable Index" in the Zope 2 distribution, as well.

Again, why?

I have no problems to donate "AdvancedQuery" and/or "Managable Index"
to the Zope Foundation *BUT* I will not modify the code to bring
it in line with the different style requirements usually applied
to Zope components: e.g.

  * my code uses 2 blank indentation rather than the usual 4 blank
    (to make it more readable and easier to maintain for me)
* I much prefer unit tests over doctests; thus, "AdvancedQuery"
    and "Managable Index" come with extensive unit tests and no

  * I use camel case also for parameters and local variables
    and not only for functions and "global" objects.

Is there interest in "AdvancedQuery" and/or "Managable Index"
to become part of the Zope 2 distribution under these conditions?

With that many +1 votes already, it might seem kinda pointless, but I'm -1. It's not a strong -1 but nevertheless a -1.

Here's *why*:

* I think Dieter is doing an excellent job at maintaining his products, why should that maintenance now become a burden of the Zope 2 maintainers? Why burden, you might ask? Because it's an "alien" product that is all of a sudden adopted into Zope. I'd think most of us aren't familiar with its code base, let alone being able to do bugfixes. If we adopt it into Zope core, we're bound to maintaining it forever, no matter what Dieter decides to do...

* As Dieter outlines above, he prefers a few different styles. Code in and *especially* code in Zope core should conform to a certain style. I'm not necessarily talking about doctests vs. unit tests, but a certain kind of code arrangement (and that includes developer-orienteded docs such as doctests nowadays) are appreciated. Why should we go thru the hassle of giving AdvancedQuery a do-over? I don't think anybody would appreciate all that work nor would Dieter probably appreciate his codebase to be changed (well, he *is* willing to donate this thing, so I'm sure he's ok with taking that risk, but still... is it really necessary?).

* Plone is shipping with lots of products already, I don't see why it simply can't ship with another one. Seriously, why? Plus, if they're really trying to solve problems for Plone 3, then it seems to be too late already. The target platform, Zope 2.10, is feature-frozen since long.

If this is all about Zope 2.11 and future release of Zope, I would like to direct your attention to one of my recent proposals,, which I have plans for implementing in Zope 2.11. This propsal will allow us to package products like Dieter's excellent ones as Python Eggs and deploy them like any other package. So, if Plone really didn't want to ship with AdvancedQuery et. al., they could simply use the setuptools' dependency mechanism to at least depend on that egg. Hanno Schlichting has shown how powerful zc.buildout can be in this area with 'ploneout' already.

It might not be a popular opinion in Zope 2 land where people would like to have as much working out of the box as possible, but I think we oughta think about making Zope 2 rather smaller than bigger (where "smaller" doesn't mean "ship with less stuff" but "have fewer inter-dependencies" so that it's better reusable). An Egg-based deployment mechanism with explicitly defined dependencies will allow us to do so.

-- -- Professional Zope documentation and training
Next Zope 3 training at Camp5:
Zope-Dev maillist  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to