Tres Seaver wrote:
>>>>>>> - Deprectaion of an older, stable alternative, *no matter how grotty,*
>>>>>>>  should go hand in hand with *lots* of confidence that the new favored
>>>>>>>  alternative really is superior, and by enough margin to make the
>>>>>>>  switch worthwhile.  In my mind, this means that the new
>>>>>>>  implementation needs to be rolled out *in production* and tested in
>>>>>>>  the wild *before* we can deprecate the older alternative.
>>>>>> I think that's a big burden for refactorings. Under such a rule, Jim
>>>>>> wouldn't be allowed to roll out neither his adapter registry
>>>>>> improvements nor his Component Architecture simplification.
>>>> Refactorings *need* a bigger burden than we have recently been imposing:
>>>>  - Doing a refactoring right means adding BBB code, which itself
>>>>    increases the maintenance burden for core developers.
>>>>  - As an example, the twisted server became the *default* in Zope 3.2
>>>>    in spite of the fact that it broke ZEO because the developer who
>>>>    landed the change doesn't use ZEO, and hence missed seeing the
>>>>    damage.
>>> I guess we didn't have enough tests. Now we have a test that exercises
>>> ZEO. Plus, we dealt with this problem before any final release (perhaps
>>> even before the beta?). That's what alpha and beta phases are for...
> My point here is that the 'refactor mercilessly" meme has left people
> feeling free to make chnages of debatable value (Twisted is *still* not
> accepted in the Zope community as a superiour choice for publishing
> HTTP),

With the current efforts of bringing Twisted to Zope 2, I'd say that's a
debatable argument. But I can see that you haven't accepted it as a
superior choice. Which is fine. But that's part of another discussion. I
presume there were proposals back then and there were numerous
discussions revolving around this topic.

I realize you've been bitten by some dumb deprecations, but as far as I
can see, they were all a) in Zope 2, b) made without a proposal, c)
probably not discussed.

Like Craeg Strong wrote in this thread, deprecation per se isn't bad. It
just has to be done carefully and right. He suggested that deprecation
warnings shoudl be very clear about what has changed and what the new
way of doings things is. I've tried to follow this paradigm when
deprecating a bunch of ZCML directives (ReducingTheAmountOfZCMLDirectives).

> without full weight being given to the needs of folks who aren't
> up to their elbows in the code every day.
>>>>  - The packaging changes introduced in the 2.9 release cycle broke
>>>>    usecases which many developers care about ('make inplace' is broken,
>>>>    instance home testing broke, etc.)  Worse, and ironically, the
>>>>    breakage was incurred on behalf of 'zpkg', which is itself slated
>>>>    (now) to be deprecated.
>>> Forgive me if I'm a little rough on this subject, but here it goes:
>>> I've had it with this whining about make inplace etc. It's been nearly
>>> half a year since 2.9 is out and nobody has even made the attempt to fix
>>> this so I guess nobody really needed it. Yet there's still whining. Yes,
>>> I'm to blame for bringing zpkg to Zope 2 because the Zope 3.2 build
>>> process strongly suggested it. If there were alternatives to zpkg,
>>> nobody has suggested them and nobody seems to have explored them so far.
>>> All I know is that everyone wanted Zope 3.2 in Zope 2.9 which is what
>>> they got.
> Zope 3 is a *library* for Zope 2 -- I don't see any necessary reason to
> have Zope 3's packaging model drive Zope 2's.

As you describe it below, it was the easiest and first choice back when
I brought Zope 3.2 into Zope 2.9. My main objective was to bring Zope
3.2 up to date with Zope 2.9, not changing Zope 2's packaging mechanism.
Perhaps it was wrong doing it anyways just for the sake of having Zope
3.2. Rest assured I won't do anything like that again, anyways. All I'm
saying above is that when people pointed out the issues, they could've
helped fix them also. A fix would've included NOT using zpkg in the
final release which would have been perfectly ok with me.

Anyways, we're drifting into a "what would have been if" discussion
which is a bit pointless. I like that you

>     o Generate a "release distribution".
>     It cannot be used as the basis for running developer sandboxes, at
>     least not without major hacking of the generated instances.  Here is
>     a sample:
>      $ svn co $ZSVN/Zope3/branches/3.2 Zope-3_2-branch
>      ...
>      $ cd Zope-3_2-branch
>      $ /path/to/python build_ext -i

You're missing another distutils command:

  $ /path/to/python install_data --install-dir .

That's why it barfs below. I usually just type 'make' which does both.

>      ...
>      $ /path/to/python utiltiies/ -d /tmp/z32
>      ...
>      $ cd /tmp/z32
>      $ bin/zopectl fg
>      ...
>          ConfigurationError: ('Unknown directive',\
>            u'', u'role')
>     I don't think this is a useful place for us to be in Zope 3, and I
>     *don't* want to emulate Zope 3 in this direction in Zope 2.  I would
>     in fact be in favor of a return to the used in Zope 2.8,
>     as a precursor to a Zope 2.x release built around eggs, rather than
>     zpkg.

Yes, that would be great. I support such a move.

>>> I also think it makes it hard to understand. In response to this
>>> proposal, several people have asked me "By the way, what's the
>>> difference between <browser:page /> and <browser:view /> anyhoo?" That
>>> alone has proven my point that the current system makes it absolutely
>>> incomprehensible of what's going on behind the scenes.
> Documenting ths *semantics* of the current implementation isn't that
> tough;

It is, if you want people to understand what's going on ("Will I need a
base class?" - "No" - "Where does 'context' and 'request' come from?" -
"A base class" - "Uh huh"). Also see the example at

It's not like I'm making up my reasons for doing this. All of my recent
attempts to make ZCML clearer and easier to understand comes from other
people's feedback (readers, customers, etc.)

> explaining the *implementation*, on the other hand, is plenty
> hard.  I'm all in favor of simplifying the implementation, as long as we
> don't induce gratuitous breakage on the developers and admins who
> followed our lead and installed Zope3 (or Zope2 and Five) already.

The implementation is hard to maintain. Gratuitous changes might be
possible. I'm not sure it's worth it. I won't do it. I'd rather get it
right now. The readers of my book won't benefit from it, sure. But the
readers of my *next* book will :)

Either way, I've seen there's a lot of resistance against changing the
existing directives. I'll therefore make the ones I propose separate.


Zope3-dev mailing list

Reply via email to