openstack team mailing list archive

[Maru Newby <mnewby@xxxxxxxxxxxx>]

Hi Keven,

On 2012-03-08, at 8:31 AM, Kevin L. Mitchell wrote:

> On Wed, 2012-03-07 at 22:40 -0800, Maru Newby wrote:
>> I'm using a devstack-configured box with all the latest code and am
>> running into DeprecationWarning wherever
>> weob.Request.str_[GET,PUT,cookies,params] are accessed (they are being
>> replaced by unicode equivalents).  Since Python < 2.7 does not ignore
>> DeprecationWarning, and I am running on Python 2.6, the warnings are
>> being thrown as exceptions.
> 
> They're being thrown as exceptions?  I thought the default in Python 2.6
> was to report them, not to throw them.  Did someone change the warnings
> settings to throw instead?

I was initially confused by the fact that DeprecationWarning can be both raised and used to set the category for a warning (e.g. warnings.warn('deprecated', DeprecationWarning)).  Warnings are reported, and that reporting can be configured to hide a given warning (as Python 2.7 hides warnings with category DeprecationWarning by default).  Exceptions are exceptions, period.

I've traced the source of my problem to melange - I added it to the services for devstack to configure, and melange includes a bare 'WebOb' dependency in pip-requires.  This resulted in WebOb 1.2b3 being installed, and breakage in just about every service (except melange, of course), since the deprecated WebOb.Request properties that resulted in warnings for previous WebOb versions raise exceptions as of version >= 1.2.

I will file a bug and fix the bad dependency in melange.

It does begs the question of managing versions of shared pip dependencies.  It might make sense to have an authoritative list of shared dependencies that doesn't change until all projects are tested to work with the new version - or does this already exist?  Another option would be to install each service in its own isolated venv - this would likely be preferable for devstack to allow version skew in development.


>> 1. Should DeprecationWarning be ignored by OpenStack projects when
>> using Python < 2.7?
> 
> I vote 'no' on development.  I'd say it makes sense to ship final
> releases with deprecation warnings disabled, but they exist to warn us
> developers that some interface is going away, and we should pay
> attention to that.  That said, unless you're specifically hunting
> deprecation warnings, I wouldn't set them up to throw exceptions…

Now that I'm clear on what was actually happening, this question is moot.


>> 2. If no to #1, should OpenStack projects be proactively surveyed for
>> use of deprecated webob.Request properties, with an eye towards
>> replacing such use immediately?  Note that the string properties will
>> not be removed until WebOb 1.2 and all projects are currently on
>> 1.0.8.

I will survey all WebOb-dependent projects and file bugs for those affected.  Is it possible to group bugs across projects? 

> 
>> 3. As a follow-on to #2, is there going to be any fallout from
>> switching from string to unicode webob.Request properties?  Web apps
>> generally code defensively against non-ascii input, but being new to
>> OpenStack I'm not sure how well this best-practice has been adhered
>> to.
> I think the only way to really know is going to be to go there and
> exercise it, then make sure everything handles it OK.  Maybe we should
> consider some unit tests?

I'll make mention of this in the bugs that I file, with an eye towards evaluating whether the existing unit tests evaluate are sufficient.

Thanks,


Maru