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 and into these directives were mostly (though not entirely) about 
security anyway, and the move didn't introduce new dependencies.



Zope-Dev maillist  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to