Derek Broughton wrote:
Martin Aspeli wrote:
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.
That just sounds to me to be another reason why I should never use
getToolByName.
I don't think this has anything to do with the thread. It was just an
example. What if you imported IContentish? Or anything else from any
other package.
Any direct dependency should be declared. You can get away without doing
it, but that exposes you to more risk of breakage in the future. If
you're experienced enough to make calculations about the risk of
breakage vs. the time you save by not adding a line to setup.py, go
ahead and make the judgment. But if you're not, follow the rule of thumb
above.
I'm afraid I still don't understand why
"getToolByName(context, 'portal_catalog')" is more correct than
"context.portal_catalog".
For one thing, it's a lot easier to understand for anyone reading your code.
The fact that you're acquiring that tool from the portal root is just a
(pretty stupid) implementation detail. What you're really doing is
asking the framework to give you a handle on the catalog so you can use
it. When (not if) tools stop being acquirable like this, you'll get no
sympathy for having to change your code. ;)
Also, it provides some safety (for certain known tools, at least)
against clashing names in the acquisition chain.
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
