Re: Zope 2.12.9 broke ZMySQLDA in the middle of a stable release series

Hi

On Tue, Jul 13, 2010 at 12:44, Hanno Schlichting <[email protected]> wrote:
> [...]
>
>> You'll get the following traceback:
>>
>> Traceback (most recent call last):
>>  File "bin/py", line 107, in <module>
>>    exec _val
>>  File "<string>", line 1, in <module>
>>  File "/home/leo/opt/zmysqlda/eggs/Products.ZMySQLDA-3.1-py2.6.egg/Products/ZMySQLDA/__init__.py",
>> line 90, in <module>
>>    import DA
>>  File "/home/leo/opt/zmysqlda/eggs/Products.ZMySQLDA-3.1-py2.6.egg/Products/ZMySQLDA/DA.py",
>> line 243, in <module>
>>    os.path.join('Shared','DC','ZRDB','www','DBAdapterFolder_icon.gif'))}
>>  File "/home/leo/opt/zmysqlda/eggs/Zope2-2.12.9-py2.6-linux-x86_64.egg/App/ImageFile.py",
>> line 77, in __init__
>>    stat_info = os.stat(path)
>> OSError: [Errno 2] No such file or directory:
>> '/home/leo/opt/zmysqlda/eggs/Zope2-2.12.9-py2.6-linux-x86_64.egg/Shared/DC/ZRDB/www/DBAdapterFolder_icon.gif'
>
>> The most trivial fix seems fairly obvious: ZMySQLDA should carry its
>> own icon, but in any case, Zope 2.12 should not break compatibility in
>> the middle of a stable series. I strongly suspect other Zope2 DB
>> adapters to suffer from the same problem.
>
> We documented it pretty clearly in the Zope 2.12.0 release notes, that
> you can no longer rely on software home or zope home. See for example
> http://docs.zope.org/zope2/releases/2.12/WHATSNEW.html#fully-eggified
>
> The code should have long been changed to import Shared.DC.ZRDB and
> then os.path.join(ZRDB.__file__, 'www', 'DBAdapterFolder_icon.gif') or
> better yet use its own icon. Both of these would have worked with all
> 2.12.x releases.

the call that failed is this:

ImageFile(os.path.join('Shared','DC','ZRDB','www','DBAdapterFolder_icon.gif'))

There is no explicit mention of "software home" anywhere, and there
was no warning that this API was being used in a deprecated way.

In fact, the use of software home happens inside ImageFile itself:

    def __init__(self, path, _prefix=None):
        import Globals  # for data
        if _prefix is None:
            _prefix=getattr(getConfiguration(), 'softwarehome', PREFIX)
        elif type(_prefix) is not type(''):
            _prefix=package_home(_prefix)

Of course I and most people on this list can read the ImageFile() call
above and probably get a good hunch that sofware_home is being assumed
somewhere, but a cursory reading of the call could also imply that a
data file is simply being read relative to the Zope2 package location,
and that this is supported behaviour of the ImageFile class.

>> I'm not sure what the proper fix should be. App.ImageFile.ImageFile
>> could grow support for icons outside of software_home, or perhaps the
>> spinning-off of Shared.DC.ZRDB should be delayed to the 2.13 series
>> only, but in any case the 2.12 branch should be a safe upgrade for
>> third party code as much as reasonably possible.
>
> We don't make guarantees on internals. Zope 2 always had a policy of
> allowing minor changes and new features to occur in the stable release
> series. It's not just pure bugfix releases.

And I'm not disagreeing with the policy, but it can be argued that
depending on the location of *data* files inside the Zope2 package is
not necessarily relying on "guarantees on internals".

> I think in this case the code in Products.ZMySQLDA should be changed
> to be compatible with Zope 2.12.

Obviously. Still, App.ImageFile.ImageFile (and any other Zope2 APIs
that do rely on software_home) should give a clear warning when
software_home is assumed, since it is the one assuming it. The
exception raised by the ImageFile call now gives no clue on what
actually went wrong and what a developer should do about it.

Cheers,

Leo
_______________________________________________
Zope-Dev maillist  -  [email protected]
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )