Andreas Jung wrote:
> --On 29. Dezember 2007 08:17:43 +0100 Hanno Schlichting
> <[EMAIL PROTECTED]> wrote:
>> Adding those deprecated but still functional packages to the KGS would
>> be one way, but seems to be a bit of work.
> I just wonder what deprecation in the future means. There were some
> discussions about the "Zope 3 app server" and its future releases..one
> thought was that there would be no further releases of the Zope 3 app
> server but only independent releases of its modules. So each module has
> its individual lifecycle and no Zope 3 app server distro will give us
> the information that a particular module is deprecated. However a component
> zope.mod1 could use zope.mod2 within some release and deprecate the use
> of zope.mod2 at some point in the future...this thought alone lets me
> shiver :-)
I don't feel in any position to predict how this story will turn out.
For Zope 2.11 it is mostly a non-issue. Let's talk about it when we
start making plans for Zope 2.12.
> Back to the original problem, the zope.app.* modules. If those modules
> are used by Zope 2 internally only then we don't need to include them.
> If third-party products depend on zope.app (I have no idea if this is
> the case) then we must put them back...
I only stumbled upon this whole problem because a plone.* package was
using "from zope.app.event" which in Zope 2.10 gave a deprecation
warning about removal in 3.5 but in 2.11 was suddenly gone. On Plone
trunk aka 4.0 the import was already made conditional, so both
zope.app.event and zope.event are tried.
The underlying problem here is that a lot of the things in the zope.app
namespace aren't really Zope App server specific and really should be in
the zope.* namespace in order to make them reusable. We have done that
move for quite a lot of packages already, but aren't anywhere near
finished. Anyone tried to use zope.formlib without zope.app.form for
> however there is a chance that these older zope.app modules produce
> errors during the tests because of possibly incompatibilities with
> newer modules. I have the strong opinion that zope.app is "something
> Zope internal" that should only be used by Zope 2/3 internal
> functionality and not by third-party apps...but perhaps I am
> wrong...no idea.
I think your idea has merit and could be a goal when we started over
again, but what we have today in zope.app isn't anywhere near that goal.
The number of imports from zope.app inside Plone are numerous, as a lot
of functionality is hidden in those packages.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -