[Product-Developers] Re: unit test on Plone 4.0b1

[Derek Broughton]

Martin Aspeli wrote:

> Ross Patterson wrote:
>> Derek Broughton<derek at pointerstop.ca>  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