[Zope-dev] [Checkins] SVN: zope.intid/trunk/ - Remove a dependency on ``zope.container.contained.Contained``
Martijn Faassen
faassen at startifact.com
Fri May 15 09:55:20 EDT 2009
Stephan Richter wrote:
> On Friday 15 May 2009, Fred Drake wrote:
>> Keeping the dependency graph clean is great, and there's plenty to do
>> there. But there's also something to be said about being able to keep
>> a substantial portion of it in your head. The cleanliness of the
>> graph isn't so important if most users still can't understand just
>> because there are so many pieces that they wouldn't normally use
>> directly.
>
> Yes, I have voiced that concern several times myself. I personally do not even
> understand where all this fear of installing many packages comes from. I
> think it is because the ZCML is pulling in too many default registrations and
> people are afraid of those, which I understand. But to create new packages
> just because you do not want to use other parts of it is silly.
That's not silly at all.
I'm not afraid of installing many packages for my applications. But for
libraries and little frameworks, I don't like having to depend on 70
other packages even though my library isn't using 99.9% of the code in
there in any way. Is that silly?
We created zope.container because we don't want to use all the code in
zope.app.container. zope.app.container contains the ZMI a lot of code we
don't want to be there in our apps as we're not intending to use it. Is
that silly?
The zope.browser package was created to prevent, among other things,
z3c.form from pulling in code from zope.formlib, a completely separate
form library. But it wasn't a good situation. People actually got
confused and thought they had something to do with each other, in that
z3c.form uses zope.formlib, which it doesn't. Is preventing that
situation silly?
The principle has to do more with *less code* than *less packages*.
We're trying to make it possible to use and be aware of less code when
considering individual chunks of the code base. To create loose coupling
so that you don't have to worry about all chunks of the codebase even
though you're only concerned with a little bit of it. To get rid of the
code that isn't used a lot (such as the ZMI).
If we can make our zope.* packages not rely on a huge amount of other
packages that they aren't really using anyway, we stand a larger change
understanding them ourselves, and we stand a larger change others might
understand them too and adopt them.
I could understand these concerns with package creation better if people
would point out how the total amount of packages installed for an
application or library is increasing (once the applications and
libraries have been adjusted to import from the new locations). But I
think the amount of packages is decreasing...
Regards,
Martijn
More information about the Zope-Dev
mailing list