Martin Aspeli wrote:
> I see no problem with starting with zope.component, but I'd consider
> both naming conventions and package structure conventions in a wider
> context before making the leap with zope.component, to reduce the chance
> of inconsistencies in the future.
We already had a rather fruitless naming discussion, which is why I'm
still in favor of option c) (avoiding the creation of new packages where
possible). Option b) risks us creating a lot more small packages that
we'll have to manage, and ultimately I'd like to *reduce* the amount of
packages in the Zope framework. And as I already said, I like small steps.
I think we should adhere to the principle that a package should have the
code and dependencies to run its tests, with typically no test extras
needed therefore, and no dependencies just to support testing.
I think we should also have the principle that code to configure a
concepts introduced by a package (such as component configuration,
security configuration) should be in that package, if at least this
doesn't expand dependency requirements.
I saw that this principle seemed to work fairly well when we moved ZCML
directives out of both zope.app.security and zope.app.component into
zope.security: these directives were mostly (though not entirely) about
security anyway, and the move didn't introduce new dependencies.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -