Ben Nemec wrote:
On 12/03/2014 02:45 PM, Sean Dague wrote:
So this -
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:

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

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 mailing list

Reply via email to