Open Stack

I really have to agree with this. It's especially important if oslo.messaging is also used in libraries like taskflow. If oslo.messaging imposes that users of it must use oslo.config then by using it in taskflow, taskflow then imposes the same oslo.config usage. This makes all libraries that use it inherently only useable in the openstack ecosystem which I think is very bad opensource behavior (not exactly open). There are other reasons to, a configuration dict means u can have many different active instances being simultaneously used (each with its own config), with oslo.config since it is a static configuration object u get 1 simultaneous instance. So this is yet another behavior that I as a library provider thing is very unhealthy restriction to impose on people that use taskflow.

Sent from my really tiny device...

> On Dec 6, 2013, at 6:46 AM, "Julien Danjou" <julien at danjou.info> 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.
> 
> -- 
> Julien Danjou
> ;; Free Software hacker ; independent consultant
> ;; http://julien.danjou.info
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev