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" <mar...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
