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'm afraid I still don't understand why "getToolByName(context, 'portal_catalog')" is more correct than "context.portal_catalog". -- derek _______________________________________________ Product-Developers mailing list [email protected] http://lists.plone.org/mailman/listinfo/product-developers
