[Zope-dev] CatalogPathAwareness and zope.lifecycle

[Sascha Welter]

(Fri, Apr 15, 2011 at 02:39:26PM +0200) Hanno Schlichting wrote/schrieb/egrapse:
> > I assume this kind of thing has been discussed and the decision has been
> > taken on judging backwards compatibility vs. the benefits of doing this?
> 
> The particular code was unused for several years,

Sigh. Sorry Hanno, but just *sigh*.

"Unused"? Unused by whom? There is code out there that uses stuff
without you or anybody else typing in the code on a keyboard. How can
you claim it's unused? Do you make audits on what pieces of code people
use in their Zope projects?

People want to be able to move an existing Zope app to a new server and
a new Zope install there without having to sell the customer onto 15
hours of maintenance coding to fix 100 things that break. Not every
project is a new project.

> using manage_*
> methods is deprecated since Zope 2.8 or 2.9.

You are wrong.

CHANGES.txt in Zope 2.11 does not know anything about manage_*
being deprecated. Instead it says:

- Turned deprecation warnings for manage_afterAdd, manage_beforeDelete
  and manage_afterClone methods into discouraged warnings. These
  methods will not be removed in Zope 2.11, but stay for the
  foreseeable future. Using events is still highly encouraged.

The CHANGES.txt from 2.12 says:
"Downgrade the ``manage_* is discouraged. You should use event
subscribers instead`` warnings to debug level logging. This particular
warning hasn’t motivated anyone to actually change any code."
And it will damn sure not motivate anybody, because code that uses that
runs just fine (thank you) and nobody sees any need to "fix" it to use
something that is undocumented and not tested in that particular setup.
That's not how maintenance on a working system works.

CHANGES.txt in 2.13 doesn't know anything about manage_* being
deprecated or removed any further.

If it doesn't break anything, if it doesn't break new code, why
depreciate and why remove it? We've had this same game with zLOG and
manage_afterAdd before. They're both still here, for good reason.

> If you really need this code, just copy it from an old release into
> your own codebase.

How about you don't delete it and I don't have to add it back?
Less work for you, less work for me, less work for everybody.

> Developing with Zope 2 is probably a frustrating experience, but that
> shouldn't come as a surprise to anyone.

It comes as a surprise to me. In fact, I find developing with Zope 2
quite an amusing and entertaining experience. And easy. You must be
doing something wrong.

I can understand though that Zope is not a system for newbies to start
*right now*, OK.

> The project is dead for
> several years now and is only kept left alive while Plone is migrating
> away from it or some long time developers are still using it. It's a
> large piece of legacy code that has no future - certainly not for new
> users or developers not already familiar with it.

Well, I don't know anything about what Plone is or isn't doing. No Plone
was ever able to move to a different Zope version without rewriting
basically everything, so maybe you think that's normal. It isn't like
that for most everybody else though.

IMHO the way to treat a "large piece of legacy code" is *not* to break
various things inside it because some other idea to do things seemed so
much cooler a while back (but which we also abandoned, because we'll get
rid of it all anyway).

The way to do that properly is to make it as stable an lasting as you
can and let it stay alive till it falls over by itself. So if you think
it's dead, OK, but there is no reason to actively kill it piece by piece.

Regards,

Sascha