[Zope-dev] Uses of the ZTK and how it relates to management

[Brian Sutherland]

On Thu, Mar 04, 2010 at 10:09:26AM -0500, Jim Fulton wrote:
> On Thu, Mar 4, 2010 at 5:35 AM, Hanno Schlichting <hanno at hannosch.eu> wrote:
> > On Thu, Mar 4, 2010 at 7:19 AM, Christian Theune <ct at gocept.com> wrote:
> >> A thought that came up when reading this paragraph: another option
> >> restructuring/grouping to reduce the amount of packages may be to join
> >> smaller packages with weird boundaries into larger ones again. (Not that
> >> I suggest this to be an ultimate option, nor do I know from the top of
> >> my head any candidates for this, but we can keep that on the list of
> >> options we have.)
> >
> > I think this is a good idea, but I wouldn't want to do it on a package
> > level. Rather do it on the distribution level. Once the distutils2
> > improvements are available, we have the means to say "distribution A
> > obsoletes B".
> >
> > As a simple example that would allow us to put zope.event into the
> > zope.component distribution, without having to change any import paths
> > or setup.py install_requires lines. The zope.component distribution
> > would have the metadata to say "I obsolete zope.event", so if someone
> > has such a version of zope.component, requirements of the zope.event
> > distribution would be automatically satisfied.
> >
> > This same method could be taken to build more functional distribution
> > out of related packages we have today. These distributions might also
> > be easier to market, document and explain. But they come with the
> > downside of more buy-in per distribution. Figuring out how packages
> > are actually used and which ones are used independently is no small
> > task.
> 
> Your description of the mechanism sounds interesting.
> 
> In the specific case of zope.event, I'd prefer it stay separate.  I
> want developers to be able to publish events without having to commit
> to a subscription mechanism.  For example, ZODB depends on zope.event
> so it can generate events and provide a generic hook mechanism. I
> don't want it to depend on zope.component.

I just committed a jinty-optional-event branch for zope.component that's
an experiment as to how to make the dependency on zope.event optional.

zope.event will still be used if it is around but zope.component will
provide it's own implementation if not. Other packages which only depend
on zope.component can break their dependency on zope.event.

> Ideally, I'd like other projects to adopt zope.event, or for something
> like zope.event to be included in the standard library, although, I'm
> unlikely to push that politically, so it will probably never happen.
> :/
> 
> Jim
> 
> -- 
> Jim Fulton
> _______________________________________________
> Zope-Dev maillist  -  Zope-Dev at zope.org
> 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 )

-- 
Brian Sutherland