Open Stack

Ben Nemec wrote:
> On 12/03/2014 02:45 PM, Sean Dague wrote:
>> So this -
>> https://github.com/openstack/oslo.messaging/commit/bcb3b23b8f6e7d01e38fdc031982558711bb7586
>> was clearly a violation of our 1 cycle for deprecation of config options.
>>
>> I think that should be reverted, an oops release put out to fix it, and
>> then deprecate for 1.6.
>
> +1.  That was definitely a no-no.
>
>> If oslo libraries are going to include config options, they have to
>> follow the same config deprecation as that's a contract that projects
>> project up. Otherwise we need to rethink the ability for libraries to
>> use oslo config (which, honestly is worth rethinking).
>
> I don't see how that would help with this sort of thing.  Instead of one
> project mistakenly removing an undeprecated opt, you would have dozens
> potentially making the same error, which would also then make their
> available configuration options inconsistent with all of the other
> projects using oslo.messaging.  That way lies madness.

Isn't this the way most other libraries that don't use oslo.config 
operate? Aka, the API they expose would follow deprecation strategies 
that libraries/apps commonly use. It has always been sort of 
tricky/hidden (IMHO) that the usage of oslo.config is really a part of 
those libraries public API.

Example that shows what people might do:

# Using oslo-config as the API
def a(cfg):
   if cfg.b:
     print("hi")

# Using an actual kwarg
def a(b=False):
   if b:
     print("hi")

Now to deprecate the kwarg using function there needs to be some kind of 
warning logged when 'b' is provided that recommends the new name (say 
'c'); this is similar to what the oslo-config using API also has to do 
but I feel it's less obvious and easier to break; since it isn't clear 
from the function definition this is happening since the function still 
gets just a 'cfg' object, and this just gets worse if u continue passing 
around the cfg object to other functions/methods/classes...

Basically the only way to really know that someone is using 'cfg.b' is 
by grepping for it (which makes the API very malleable, for better or 
worse; it also seems to make it harder to use tools like sphinx that can 
interpret function pydocs to denote functions that have depreciations 
and such...).

IMHO it doesn't seem like the larger pypi/python world has gone to mad 
(aka those projects, apps, libraries, others that haven't used oslo.config)?

But maybe I missed all the mad people or I'm in the crowd that is mad 
and I can't tell ;) To me the inconsistency that you state is a 
policy/people problem and need not be addressed always by oslo.config 
(but could just be addressed at say review time).

I know not everyone agrees with this, but it's useful to think of 
different ways and at least think about them...

>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev