[Zope-dev] Zope Toolkit - packages with zope.app dependencies

[Hanno Schlichting]

Good morning :)

On Sun, Dec 27, 2009 at 5:11 AM, Martin Aspeli <optilude+lists at gmail.com> wrote:
> 2009/12/27 Hanno Schlichting <hanno at hannosch.eu>:
>> The Zope Toolkit is explicitly not a framework or application server -
>> it shouldn't contain any zope.app packages, neither directly nor as
>> test dependencies. Zope2 trunk which is based on the real ZTK doesn't
>> use any zope.app packages anymore. So I don't want to buy into the
>> maintenance burden of zope.app any longer.
>
> I get that, but on balance dropping zope.intid from the ZTK seems the
> greater of two evils. I'd rather it was left in with some hair
> *test-only* dependencies until we have time to refactor it, rather
> than drop it until such time, because:

The specific way we set up the ZTK causes all dependencies of a
package to become part of the ZTK version list. If we leave zope.intid
and catalog in, we also need to leave the 36 zope.app packages they
depend on in it. With those two being the last packages causing this
problem, I think it's reasonable to turn the responsibility around.
Those who are specifically interested in these two packages should
make sure they behave. Once they do, I want them to be part of the ZTK
again. But at this point I'm not willing to have two packages incur a
maintenance burden of a large part of zope.app on toolkit developers
anymore.

>  - Consumers of the ZTK are using zope.intid in the wild right now

Well, kinda. Neither repoze, Zope2, CMF or Plone actually use it in
their core, only Grok does - but that's not the point ;)

>  - Since it was renamed from zope.app.intid to zope.intid, I think
> there's been an expectation that this was a "safe" package to depend
> on; removing it from the ZTK implies a smaller group of people who're
> willing to help maintain it

It's a perfectly save package to depend on. But it needs people who
want to maintain it, not force everyone who has an interest in the ZTK
to maintain it.

>  - Centralised unique id management is an important category of
> service that is likely to be more useful if there is one canonical
> implementation that "everyone" can depend on - if different consumers
> of the ZTK end up inventing their own approach to this use case, that
> will likely detract from cross-framework reuse

Sure. It should be in the ZTK, I don't argue against that. But it
needs to play by the rules before it gets to be part of it.

Hanno