On Tue, Mar 2, 2010 at 2:18 PM, Chris McDonough <chr...@plope.com> wrote:
> On 3/2/10 1:09 PM, Martijn Faassen wrote:
>> Hi there,
>> > Chris McDonough suggests to ponder further structuring of the ZTK into
>> > separate sub-sets which might allow us to get better mileage regarding
>> > maintenance and release management. He gave the example of the
>> > "Bicycle Toolkit" (zope.component, zope.configuration,
>> > zope.interface).
>> We already have had issues with people changing things in ztk.cfg that
>> broke things in zopeapp.cfg, because they don't want to test it. If we
>> were to split things further, we'll see more breakage and more
>> integration issues as people won't bother to test even less.
> I don't know who "people" are, and I don't know who "they" are, and I don't
> know who broke what.
> The reward is increased potential for reuse outside the various Zope framework
> stacks. It'd be a lot more palatable for people to see docs and a website for
> a notional "Zope Form Generation" package that it would be for them to need to
> extract such a thing from "the ZTK" wholesale. Splitting things across
> functional boundaries like this would put a more reasonable end-user face on
> zopey things I think. And maybe I wouldn't have to rewrite everything all the
> time due to people freaking out about things named "zope.*" if they were
> organized into functional categories.
I think you're confusing management and reuse (packaging including
dependencies). We all want people to be able to reuse parts of the
ZTK. There's broad agreement that we want to clean up dependencies.
What's being advocated by many of us is that the ZTK be managed as a
whole (for some definition of the whole that shrinks somewhat over
time) to allow us to clean things up without causing breakage for
people using the ZTK.
No one should have to extract anything from the ZTK, because, AFAIK,
the ZTK isn't a distribution.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -