[MERGE] 1.5? Suppress DeprecationWarning in official releases

John Arbash Meinel john at arbash-meinel.com
Wed May 28 23:00:32 BST 2008

Hash: SHA1

Martin Pool wrote:
| On Sat, May 17, 2008 at 1:24 AM, John Arbash Meinel
| <john at arbash-meinel.com> wrote:
|> Hash: SHA1
|> Martin Pool wrote:
|> | Martin Pool has voted tweak.
|> | Status is now: Conditionally approved
|> | Comment:
|> | I think this should be in NEWS.
|> |
|> | I think this is a reasonable tradeoff.  I do sometimes run Bazaar with
|> | -Werror and it would be nice if this did not override the -W flag when
|> | that is specified, especially for selftest.  But I'm OK to go back and
|> | fix that later, if it turns out that it is broken.  Perhaps eventually
|> | the test suite should hook into warnings and specially report them.
|> Actually, this breaks our python -Werror for the test suite... Thanks for
|> bringing that up.
|> We *want* DeprecationWarnings to cause the test suite to fail when run on
|> PQM.
|> Should I change it so that selftest always makes DeprecationWarnings =>
|> "error".
|> That might be annoying if you just have a plugin installed.
|> My original idea was that people running 'selftest' with a release
|> installation
|> wouldn't want 'ignore', and AFAICT there isn't a good way to just remove a
|> filter (without resetting the whole thing).
|> So I'll take out the line in 'cmd_selftest', as at least it lets PQM fail if
|> DeprecationWarnings are emitted.
|> I could also inspect 'warnings.filters' but I'm not a big fan of that.
| It does seem a bit icky to look inside a standard library's globals,
| but that does seem to be how you can edit the existing filters.  (And
| in a way letting you just read the list is more pythonic than
| requiring a specific api for everything...)
| I think the behaviour we want is this (in order):
| 1. If -Wanything is given, stick with what was specified.
| 2. For release versions, give no warnings.
| 3. Otherwise, warn once.
| I think having no special case for cmd_selftest is acceptable so long
| as it can be turned back on by -Werror.
| To do the first I think you will have to look in warnings.filters.

The attached patch does this for -Werror. I thought about doing it for
- -Wanything, but the problem is that I can't tell the difference between
"-Wignore" and someone calling suppress_deprecation_warnings() (which main()
will do if someone runs a release bzr).

I added tests for everything as well, since I had to work out how to inspect
warnings.filters anyway. This doesn't pay attention if someone would do
something like "-Wfoo:error" or some other custom handling, but it works for
what *we* do as a project, which is enough for me.

Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dep_warnings.patch
Url: https://lists.ubuntu.com/archives/bazaar/attachments/20080528/f22ea0ba/attachment.diff 

More information about the bazaar mailing list