Re: Zope Toolkit - packages with zope.app dependencies

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hanno Schlichting wrote:
> Good morning :)
> 
> On Sun, Dec 27, 2009 at 5:11 AM, Martin Aspeli <[email protected]> wrote:
>> 2009/12/27 Hanno Schlichting <[email protected]>:
>>> 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.

The whole point of breaking the monolith up was to allow for different
maintainers, release cycles, etc.  Pushing non-conformning packages out
of the ZTK does *nothing* to harm the current users of such packages:
it just signals the (already existing) condition of (non)maintainership
of those packages.

>>  - 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.

Amen, brother!


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          [email protected]
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAks29ooACgkQ+gerLs4ltQ4bDgCeNaWLIhWsIaAn87lqKiIw3Chc
Z7EAn1B28ytkCiNcVWepvJvb1GZdLHgR
=OU5p
-----END PGP SIGNATURE-----

_______________________________________________
Zope-Dev maillist  -  [email protected]
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )