Open Stack

Could jsonschema[1] be used here to do the options schema part? It works on dictionaries (and really isn't tied to json). But maybe I am missing some greater context/understanding (see other emails).

[1] https://pypi.python.org/pypi/jsonschema

Sent from my really tiny device...

> On Dec 6, 2013, at 7:12 AM, "Mark McLoughlin" <markmc at redhat.com> wrote:
> 
>> On Fri, 2013-12-06 at 15:41 +0100, Julien Danjou wrote:
>> On Fri, Dec 06 2013, Mark McLoughlin wrote:
>> 
>> Hi Mark,
>> 
>>> If the goal is "allow applications to use oslo.messaging without using
>>> oslo.config", then what's driving this? I'm guessing some possible
>>> answers:
>>> 
>>>  5) But I want to avoid any dependency on oslo.config
>> 
>> I think that's the more important one to me.
>> 
>>>     This could be fundamentally what we're talking about here, but I 
>>>     struggle to understand it - oslo.config is pretty tiny and it only 
>>>     requires argparse, so if it's just an implementation detail that 
>>>     you don't even notice if you're not using config files then what 
>>>     exactly is the problem?
>> 
>>> Basically, my thinking is that something like this example:
>>> 
>>>  https://gist.github.com/markmc/7823420
>>> 
>>> where you can use oslo.messaging with just a dict of config values
>>> (rather than having to parse config files) should handle any reasonable
>>> concern that I've understood so far ... without having to change much at
>>> all.
>> 
>> I definitely agree with your arguments. There's a large number of
>> technical solutions that can be used to bypass the usage of oslo.config
>> and make it work with whatever you're using..
>> 
>> I just can't stop thinking that a library shouldn't impose any use of a
>> configuration library. I can pick any library on PyPI, and, fortunately,
>> most of them don't come with a dependency on the favorite configuration
>> library of their author or related project, and its usage spread all
>> over the code base.
>> 
>> While I do respect the fact that this is a library to be consumed mainly
>> in OpenStack (and I don't want to break that), I think we're also trying
>> to not be the new Zope and contribute in a sane way to the Python
>> ecosystem. And I think oslo.messaging doesn't do that right.
>> 
>> Now if the consensus is to leave it that way, I honestly won't fight it
>> over and over. As Mark proved, there's a lot of way to circumvent the
>> oslo.config usage anyway.
> 
> Ok, let's say oslo.messaging didn't use oslo.config at all and just took
> a free-form dict of configuration values. Then you'd have this
> separation whereby you can write code to retrieve those values from any
> number of possible configuration sources and pass them down to
> oslo.messaging. I think that's what you're getting at?
> 
> However, what you lose with that is a consistent way of defining a
> schema for those configuration options in oslo.messaging. Should a given
> option be an int, bool or a list? What should it's default be? etc. etc.
> That stuff would live in the integration layer that maps from
> oslo.config to a dict, even though it's totally useful when you just
> supply a dict.
> 
> I guess there's two sides to oslo.config - the option schemas and the
> code to retrieve values from various sources (command line, config files
> or overrides/defaults). I think the option schemas is a useful
> implementation detail in oslo.messaging, even if the values don't come
> from the usual oslo.config sources.
> 
> Mark.
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev