[Zope-dev] removing zope.app from the ZTK

[Martijn Faassen]

Tres Seaver wrote:
> Martijn Faassen wrote:
[snip]
>> The ZTK cannot be an excuse to just drop support for a large part of the 
>> existing users of the ZTK. It's a *means* to do so.
> 
> What existing users does the ZTK have? 

I'll rewrite that:

The ZTK cannot be an excuse to just drop support for a large part of the 
existing users of packages that are in the ZTK, namely the users of Zope 
3.4. It's a means to do so.

We have three perspectives:

* the ZTK is new, therefore the ZTK doesn't need to care about Zope 3 at 
all.

* the ZTK is a renamed, refocused Zope 3, therefore the ZTK needs to 
care about Zope 3.

* both: the ZTK is a way for us to stop caring about Zope 3, given some 
work.

I'm in the both camp. This is a transition problem. I'm arguing in favor 
of handling this transition properly.

> I count exactly *one* user, the
> Zope2 trunk (until Hanno backed it out).  Everybody else is using some
> set of packages with a more-or-less sizable intersection with the ZTK,
> but with no explicity dependency on the ZTK manifest at all.

The Grok 1.1 alphas are based on a slightly older version of the ZTK. (I 
see you discount this as proper use of the ZTK below)

[snip]
> Because it is not relevant?  Zope2 does *not* intend to provide
> "convenience dependencies" for BBB purposes, nor does Zope2 have any
> plans for testing the no-longer-included packages in conjunction with
> those which are included:  apps / frameworks which want to move to Zope
> 2.13 will need to pull in those dependencies themselves, and do any
> appropriate maintenance / testing of them.  If that strategy works for
> the ZTK, then there is no reason to revert it to include zope.app.*.

Okay. I wonder how that's going to work out for the Zope 2 users.

I think a zopeapp KGS that will help them transition existing code from 
Zope 2.12 to Zope 2.13 in working condition would be helpful to Zope 2 
users.

> < We have a shared problem of backwards compatibility, right?
> 
> Wrong.  The strategy used for Zope2 was to eradicate use of those
> packages, and to ship 2.13 in a configuration which doesn't include them
> in any fashion.  Zope2 apps or frameworks which need zope.app pacakges
> must declare those dependencies explicitly, and assume the burden of
> maintaining / pinning appropriate / compatible versions.

Why not maintain such a list together instead of letting everybody 
figure this out themselves? It's not always easy to make sure you have 
the right packages. We were maintaining this list together, until very 
recently.

For instance, with Grok, we had a situation where we were using a newer 
version of zope.app.container by accident, thus pulling in 
zope.container in a Zope 3.4 situation. With Zope 2 I can see the 
reverse situation, where someone accidentally pins a version of 
zope.app.container that doesn't yet depend on the zope.container 
implementation. A KGS can help there.,

>> Perhaps less for Zope 2 than for 
>> other Zope Toolkit using systems, as you never used the UI or the 
>> content types.
> 
> You keep asserting a "backward compatibility problem," but haven't
> defended it with any evidence.  Be specific:  who is hurt by the removal
> of packages from the ZTK?

Everybody who uses any previous KGS, once they upgrade their codebases 
to use the ZTK. Unless they can pull in the extended list of zope.app 
packages, so that they can upgrade their app without having to assemble 
a working list of ZTK compatible versions themselves. (and then they can 
go and remove the zope.app dependencies)

> - - You can't claim that Grok users are so hurt:  they have their own KGS,
>   and have not yet made a committment to use the ZTK, where commitment
>   means doing the work required to define their superset of packages as
>   a delta to the ZTK. Instead, the Grok versions.cfg file contains a
>   *copy* of some version of the ZTK, including a bunch of zope.app
>   packages. 
>   It isn't even clear which of the zope.app packages are
>   genuinely needed by Grok, as opposed to being copied in wholesale.
>   Grok's existing test infrastructure drives of that versions.cfg file,
>   and is so insulated from any changes to the ZTK.

To copy a ZTK list is just a technical decision because we cannot rely 
on a released version of the ZTK yet. We don't want unexpected test 
breakage due to changes in the ZTK. We would certainly have had some 
unexpected breakage this week! Copying the new list without having a 
zope.app list known to work would present us with a problem.

Grok 1.1 is slated to use the ZTK (perhaps again by copying the ZTK list).

(Grok's need to have cleaner dependencies provided a large amount of the 
initial momentum into the ZTK project)

Regards,

Martijn