Re: [Zope-dev] Zope 2.12.9 broke ZMySQLDA in the middle of a stable release series
Am 15.07.2010, 13:39 Uhr, schrieb Charlie Clark charlie.cl...@clark-consulting.eu: I'll check ZPsycopgDA and make sure we look at the mxODBCZope DA as well. I'm not sure what other Products are likely to be affected by these kind of changes. Taken a while but I can confirm that this also affects ZPsycopgDA. Furthermore, the term prefix is itself misleading as it can be either an absolute path or a package dictionary. Is there a preference? Shared.DC.ZRDB.__dict__ would seem to be the easiest. How are we to deal with existence connections which seem to ignore any changes? Charlie -- Charlie Clark Managing Director Clark Consulting Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] Zope 2.12.9 broke ZMySQLDA in the middle of a stable release series
On Wed, Jul 14, 2010 at 12:22 AM, Leonardo Rochael Almeida leoroch...@gmail.com wrote: The attached patch adds such a warning, and also reveals where Zope2 commits the same sins. If there are no objections I'll commit it to 2.12 and trunk. Thanks for committing it. Finally, I'd like to ask that, when major changes land in a stable series (like the spinning off of a whole package), that we allow at least a week or two to pass before making a release, so people who have test runners for their apps running against a stable repository branch have time to adapt to the changes That sounds reasonable. I just wasn't aware that anyone except CMF actually tracks Zope 2 SVN and there would be any point in waiting at all. Unless the nightly CMF builds reported problems, I considered the code to be stable and ready for release. But to avoid any such issues, I'll restrain myself from doing any further feature changes to Zope 2.12. 2.13 is closing in fast enough and there's always a 2.14. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] Zope 2.12.9 broke ZMySQLDA in the middle of a stable release series
Am 15.07.2010, 10:35 Uhr, schrieb Hanno Schlichting ha...@hannosch.eu: But to avoid any such issues, I'll restrain myself from doing any further feature changes to Zope 2.12. 2.13 is closing in fast enough and there's always a 2.14. I'll check ZPsycopgDA and make sure we look at the mxODBCZope DA as well. I'm not sure what other Products are likely to be affected by these kind of changes. Charlie -- Charlie Clark Managing Director Clark Consulting Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
[Zope-dev] Zope 2.12.9 broke ZMySQLDA in the middle of a stable release series
Hi,
The latest Zope 2.12.9 release broke the last release of Products.ZMySQLDA.
To demonstrate, bootstrap and run the attached buildout, then run:
$ bin/py -c import Shared.DC.ZRDB, Products.ZMySQLDA
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'
Edit buildout.cfg and switch the extends directive to the commented
out 2.12.8 tag and see that the above command shows no error, only a
deprecation warning that is unrelated to the breakage above.
Internal buildbots that tracked the 2.12 branch notified me of this
problem, but in between catching up with all the traffic for the
mailing lists and the Zope commit, and a day job, I didn't have enough
time to track down the issue before the 2.12.9 release was made: there
was less than 4 days between spinning off Products.ZSQLMethods and the
new 2.12 release.
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.
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.
suggestions?
Cheers,
Leo
buildout.cfg
Description: application/httpd-cgi
___
Zope-Dev maillist - Zope-Dev@zope.org
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 )
Re: [Zope-dev] Zope 2.12.9 broke ZMySQLDA in the middle of a stable release series
Hi.
On Tue, Jul 13, 2010 at 5:13 PM, Leonardo Rochael Almeida
leoroch...@gmail.com wrote:
The latest Zope 2.12.9 release broke the last release of Products.ZMySQLDA.
You are not by any chance interested in taking over maintenance of
ZSQLMethods, are you?
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.
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.
I think in this case the code in Products.ZMySQLDA should be changed
to be compatible with Zope 2.12.
Hanno
___
Zope-Dev maillist - Zope-Dev@zope.org
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 )
Re: [Zope-dev] Zope 2.12.9 broke ZMySQLDA in the middle of a stable release series
Am 13.07.2010, 17:44 Uhr, schrieb Hanno Schlichting ha...@hannosch.eu: You are not by any chance interested in taking over maintenance of ZSQLMethods, are you? As I've still got some stuff running on ZSQL and have previously championed it I'll also wave a hand, although I'm not that familiar with the internals so am not in a position to maintain it on my own. I'd like to see a scaled back version of ZSQL survive as I think there is a compelling TTW use case but I would drop the most of the dedicated dtml-sql methods as not suitable for this kind of use. Essentially I'd like to see templates generating statements with positional placeholders to be passed to .execute(stmt, paras) calls. I'm sure I remember seeing something like SmartTemplate a few years ago which looked suitable for this. Charlie -- Charlie Clark Managing Director Clark Consulting Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] 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 ha...@hannosch.eu 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 - Zope-Dev@zope.org
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 )
Re: [Zope-dev] Zope 2.12.9 broke ZMySQLDA in the middle of a stable release series
On Tue, Jul 13, 2010 at 7:05 PM, Leonardo Rochael Almeida leoroch...@gmail.com wrote: 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'd call anything that relies on a specific file system layout to be internals. We only make guarantees on the semantics of the Python import system, not how packages and modules are stitched together in distributions and end up on the file system. 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. I agree with that. I thought the call to software home was being made inside ZMySQLDA and not in Zope 2 code. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Re: [Zope-dev] Zope 2.12.9 broke ZMySQLDA in the middle of a stable release series
On Tue, Jul 13, 2010 at 14:46, Hanno Schlichting ha...@hannosch.eu wrote:
On Tue, Jul 13, 2010 at 7:05 PM, Leonardo Rochael Almeida
leoroch...@gmail.com wrote:
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'd call anything that relies on a specific file system layout to be
internals. We only make guarantees on the semantics of the Python
import system, not how packages and modules are stitched together in
distributions and end up on the file system.
Considering that the Zope source code has a dozen examples of
App.ImageFile.ImageFile being used without a prefix (ex. OFS.misc_),
I think third party developers should be excused to think they could
follow the lead and expect their packages not to break during a stable
series.
I still think we should give them at least the 2.12 series to stop
using ImageFile incorrectly without breaking their code, but I won't
belabor the point any longer.
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.
I agree with that. I thought the call to software home was being made
inside ZMySQLDA and not in Zope 2 code.
The attached patch adds such a warning, and also reveals where Zope2
commits the same sins. If there are no objections I'll commit it to
2.12 and trunk.
Finally, I'd like to ask that, when major changes land in a stable
series (like the spinning off of a whole package), that we allow at
least a week or two to pass before making a release, so people who
have test runners for their apps running against a stable repository
branch have time to adapt to the changes
Cheers,
Leo
Index: src/App/config.py
===
--- src/App/config.py (revisão 114644)
+++ src/App/config.py (cópia de trabalho)
@@ -36,7 +36,7 @@
def setConfiguration(cfg):
Set the global configuration object.
-Legacy sources of common configuraiton values are updated to
+Legacy sources of common configuration values are updated to
reflect the new configuration; this may be removed in some future
version.
Index: src/App/tests/testImageFile.py
===
--- src/App/tests/testImageFile.py (revisão 0)
+++ src/App/tests/testImageFile.py (revisão 0)
@@ -0,0 +1,28 @@
+import unittest
+import App
+from Testing.ZopeTestCase.warnhook import WarningsHook
+
+
+class TestImageFile(unittest.TestCase):
+
+def setUp(self):
+# ugly: need to save the old App.config configuration value since
+# ImageFile might read it and trigger setting it to the default value
+self.oldcfg = App.config._config
+self.warningshook = WarningsHook()
+self.warningshook.install()
+
+def tearDown(self):
+self.warningshook.uninstall()
+# ugly: need to restore configuration, or lack thereof
+App.config._config = self.oldcfg
+
+def test_warn_on_software_home_default(self):
+App.ImageFile.ImageFile('App/www/zopelogo.jpg')
+self.assertEquals(self.warningshook.warnings.pop()[0],
+ App.ImageFile.NON_PREFIX_WARNING)
+
+def test_suite():
+return unittest.TestSuite((
+unittest.makeSuite(TestImageFile),
+))
Index: src/App/ImageFile.py
===
--- src/App/ImageFile.py (revisão 114644)
+++ src/App/ImageFile.py (cópia de trabalho)
@@ -18,6 +18,7 @@
import os.path
import stat
import time
+import warnings
from AccessControl.SecurityInfo import ClassSecurityInfo
from Acquisition import Explicit
@@ -34,6 +35,13 @@
os.path.join(os.path.dirname(Zope2.__file__), os.path.pardir)
)
+NON_PREFIX_WARNING = ('Assuming image location to be present in the Zope2 '
+ 'distribution. This is deprecated and might lead to '
+ 'broken code if the directory in question is moved '
+ 'to another distribution. Please provide either an '
+ 'absolute file system path or a prefix. Support for '
+ 'relative filenames without a prefix might be '
+ 'dropped in a future Zope2 release.')
class ImageFile(Explicit):
Image objects stored in external files.
@@ -43,9 +51,12 @@
def __init__(self, path, _prefix=None):
import Globals # for data
if _prefix is None:
-_prefix=getattr(getConfiguration(), 'softwarehome', PREFIX)
+_prefix=getattr(getConfiguration(), 'softwarehome', None) or PREFIX
+if not os.path.isabs(path):
+
