On Thu, Mar 4, 2010 at 5:35 AM, Hanno Schlichting <ha...@hannosch.eu> wrote:
> On Thu, Mar 4, 2010 at 7:19 AM, Christian Theune <c...@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
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.
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.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -