Brant, That's a great pattern for everyone to follow.
Thanks! Dims On Thu, Dec 10, 2015 at 5:21 PM, Brant Knudson <b...@acm.org> wrote: > > > On Thu, Dec 10, 2015 at 7:26 AM, Sean Dague <s...@dague.net> wrote: >> >> On 12/10/2015 01:56 AM, Joshua Harlow wrote: >> > Shouldn't be to hard (although it's probably not on each oslo project, >> > but on the consumers projects). >> > >> > The warnings module can turn warnings into raised exceptions with a >> > simple command line switch btw... >> > >> > For example: >> > >> > $ python -Wonce >> > Python 2.7.6 (default, Jun 22 2015, 17:58:13) >> > [GCC 4.8.2] on linux2 >> > Type "help", "copyright", "credits" or "license" for more information. >> >>>> import warnings >> >>>> warnings.warn("I am not supposed to be used", DeprecationWarning) >> > __main__:1: DeprecationWarning: I am not supposed to be used >> > >> > $ python -Werror >> > Python 2.7.6 (default, Jun 22 2015, 17:58:13) >> > [GCC 4.8.2] on linux2 >> > Type "help", "copyright", "credits" or "license" for more information. >> >>>> import warnings >> >>>> warnings.warn("I am not supposed to be used", DeprecationWarning) >> > Traceback (most recent call last): >> > File "<stdin>", line 1, in <module> >> > DeprecationWarning: I am not supposed to be used >> > >> > https://docs.python.org/2/library/warnings.html#the-warnings-filter >> > >> > Turn that CLI switch from off to on and I'm pretty sure usage of >> > deprecated things will become pretty evident real quick ;) >> >> It needs to be more targetted than that. There is a long standing >> warning between paste and pkg_resources that would hard stop everyone. >> >> But, yes, the idea of being able to run unit tests with fatal >> deprecations of oslo easily is what I think would be useful. >> >> -Sean >> > > In keystone we set a warnings filter for the unit tests so that if keystone > calls any deprecated function it'll raise[1]. So when the oslo timeutils > functions were deprecated it broke keystone gate and we fixed it. It would > be nicer to have a non-voting gate job to serve as a warning instead, but > it's only happened a couple of times where this caused keystone to be > blocked for the day that it took to get the fix in. Anyways, it would be > easy enough for us to have this enabled/disabled via an environment variable > and create a tox job. > > If we had a non-voting warning job it could also run oslo libs from master > rather than released. > > [1] > http://git.openstack.org/cgit/openstack/keystone/tree/keystone/tests/unit/core.py?id=4f8c4a7a10d85080d6db9b30ae1759d45a38a32c#n460 > > - Brant > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Davanum Srinivas :: https://twitter.com/dims __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev