Martin Aspeli wrote: [snip]
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. Regards, Martijn