Ross Patterson wrote:
Derek Broughton<[email protected]> writes:
Wichert Akkerman wrote:
On 3/20/10 15:33 , Derek Broughton wrote:
Thanks for this discussion - I'm loathe to even test Plone4 at the
moment beccause I don't know enough about this sort of change.
Surely, though, dependencies on something like CMFCore should be
fulfilled by declaring the dependency on Plone.
They are, but you should never rely on that: Plone might be modified
to not use CMFCore anymore itself, and your package would suddenly
break. For Plone and CMFCore that is not very likely short term, but
in general you should never rely on indirect dependencies. They
*will* hurt you at some point.
Ah, but I rather look at it the opposite way - I _should_ rely on
indirect dependencies for something like CMFCore, because I only use
it as required in Plone. If plone was to drop that dependency and use
something else (specifically this _did_ happen with CMFCore
Permissions - at least the module moved), I _want_ my product to break
and require me to fix my code. The absolutely last thing I want is
for my code to continue to import something that will only be used by
my own products while everybody else is doing something different.
+1 Well said, I've often thought this when I've heard the
above install_requires dogma.
I think the rule of thumb is pretty easy:
- if you import from a package in your own code, declare a dependency
on it
So, if you use 'from Products.CMFCore.utils import getToolByName', then
declare a dependency on 'Products.CMFCore'. If that package disappeared
from the dependency tree, your code would break.
If you don't import anything from Products.Archetypes or whatever, then
don't declare a dependency on it.
Sometimes, 'import from' can also mean 'use a ZPT macro in' or similar.
Martin
--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
_______________________________________________
Product-Developers mailing list
[email protected]
http://lists.plone.org/mailman/listinfo/product-developers
