new zope.interface deprecation warning about "implements()" #1740

New Issue

warner · 2012-05-17T00:50:06Z

warner commented

2012-05-17 00:50:06 +00:00

One of the buildslaves just started failing tests,
here.
The tests that assert tahoe start doesn't emit a lot of noise
is catching the following deprecation warnings:

src/allmydata/web/directory.py:1113: DeprecationWarning: 
The implements API is deprecated, and will not work in Python3 Use
the @implementer class decorator instead.
  implements(IPushProducer)

My guess is that there's a new version of zope.interface installed
on that box, and it's starting to work on py3 compatibility.

We need to find out what versions of zope.interface offer the
suggested replacement decorator, decide if we can tolerate being
limited to those versions, then update everything (twisted,
foolscap, nevow, tahoe) to use the replacement.

In other words, we need to either enforce a older-than dependency
restriction to avoid ever using the newer zope.interface, or add a
warning-suppression to make this noise go away :-). Actually,
that's more like :-(.

One of the buildslaves just started failing tests, [here](https://tahoe-lafs.org/buildbot-tahoe-lafs/builders/MM%20netbsd5%20i386%20warp/builds/76). The tests that assert `tahoe start` doesn't emit a lot of noise is catching the following deprecation warnings: ``` src/allmydata/web/directory.py:1113: DeprecationWarning: The implements API is deprecated, and will not work in Python3 Use the @implementer class decorator instead. implements(IPushProducer) ``` My guess is that there's a new version of zope.interface installed on that box, and it's starting to work on py3 compatibility. We need to find out what versions of zope.interface offer the suggested replacement decorator, decide if we can tolerate being limited to those versions, then update everything (twisted, foolscap, nevow, tahoe) to use the replacement. In other words, we need to either enforce a older-than dependency restriction to avoid ever using the newer zope.interface, or add a warning-suppression to make this noise go away :-). Actually, that's more like :-(.

warner added the

labels 2012-05-17 00:50:06 +00:00

warner added this to the undecided milestone 2012-05-17 00:50:06 +00:00

davidsarah commented

2012-05-17 00:55:03 +00:00

It's not just Tahoe that would have to change every use of 'implements', it's also Nevow, Twisted, and foolscap. I'm for blacklisting this version of zope.interface and telling the zope devs how silly they're being by making this a DeprecationWarning.

davidsarah commented

2012-05-17 01:01:47 +00:00

I can reproduce by forcing "zope.interface == 4.0.0" in source:src/allmydata/_auto_deps.py.

davidsarah commented

2012-05-17 01:33:17 +00:00

Attachment fix-1740.darcs.patch (109338 bytes) added

Suppress DeprecationWarnings from zope.interface 4.0.0 about use of 'implements' and 'implementsOnly'. This unifies the handling of all DeprecationWarnings that need to be suppressed globally. fixes #1740

**Attachment** fix-1740.darcs.patch (109338 bytes) added Suppress [DeprecationWarnings](wiki/DeprecationWarnings) from zope.interface 4.0.0 about use of 'implements' and 'implementsOnly'. This unifies the handling of all [DeprecationWarnings](wiki/DeprecationWarnings) that need to be suppressed globally. fixes #1740

fix-1740.darcs.patch

107 KiB

tahoe-lafs added

major

and removed

normal

labels 2012-05-17 01:34:59 +00:00

tahoe-lafs modified the milestone from undecided to 1.9.2

2012-05-17 01:34:59 +00:00

warner was assigned by tahoe-lafs

2012-05-17 01:34:59 +00:00

warner commented

2012-05-22 23:33:33 +00:00

Looks ok to me. I'd maybe add a note to make it more obvious that the warnings.filters.pop() are supposed to match the warnings.filterwarnings() calls earlier, and that global_deprecation_messages are left in place because the filter list acts like a stack (in particular, if deprecation_messages or global_deprecation_messages were a set instead of a list, it wouldn't work). I might add a comment to that effect myself after it lands.

In the long run, we should pay attention to what our fellow zope.interface-users are doing. If this decorator thing has been around long enough, and it doesn't hurt us otherwise, it might be nice to follow their advice and update the way we use implements.

Looks ok to me. I'd maybe add a note to make it more obvious that the `warnings.filters.pop()` are supposed to match the `warnings.filterwarnings()` calls earlier, and that `global_deprecation_messages` are left in place because the filter list acts like a stack (in particular, if `deprecation_messages` or `global_deprecation_messages` were a set instead of a list, it wouldn't work). I might add a comment to that effect myself after it lands. In the long run, we should pay attention to what our fellow zope.interface-users are doing. If this decorator thing has been around long enough, and it doesn't hurt us otherwise, it might be nice to follow their advice and update the way we use `implements`.

warner commented

2012-05-23 00:04:21 +00:00

Heh, so, I was about to apply this patch, and noticed that the
buildslave that was failing because of this warning (in one of the
no_noise tests) had spontaneously started passing.

Digging deeper, I learned that sometime in the last two hours,
zope.interface-4.0.1 was released, removing the deprecation
warnings: http://pypi.python.org/pypi/zope.interface/4.0.1 .
I guess they got some feedback :).

So this is now an INVALID, and the patch doesn't need to be
applied.

Heh, so, I was about to apply this patch, and noticed that the buildslave that was failing because of this warning (in one of the no_noise tests) had spontaneously started passing. Digging deeper, I learned that sometime in the last two hours, zope.interface-4.0.1 was released, removing the deprecation warnings: <http://pypi.python.org/pypi/zope.interface/4.0.1> . I guess they got some feedback :). So this is now an INVALID, and the patch doesn't need to be applied.

warner added the

invalid

label 2012-05-23 00:04:21 +00:00

warner closed this issue

2012-05-23 00:04:21 +00:00

Sign in to join this conversation.