Re: [Zope-dev] Zope Toolkit - packages with zope.app dependencies
Good morning :) On Sun, Dec 27, 2009 at 5:11 AM, Martin Aspeli <optilude+lists@gmail.com> wrote:
2009/12/27 Hanno Schlichting <hanno@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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hanno Schlichting wrote:
Good morning :)
On Sun, Dec 27, 2009 at 5:11 AM, Martin Aspeli <optilude+lists@gmail.com> wrote:
2009/12/27 Hanno Schlichting <hanno@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.
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 tseaver@palladion.com 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-----
participants (2)
-
Hanno Schlichting -
Tres Seaver