Open Stack

Avoiding namespace packages is a good idea in general. At least until Python 3.whatever is baseline. 

> On Feb 5, 2014, at 10:58 AM, Doug Hellmann <doug.hellmann at dreamhost.com> wrote:
> 
> 
> 
> 
>> On Wed, Feb 5, 2014 at 11:44 AM, Ben Nemec <openstack at nemebean.com> wrote:
>>> On 2014-02-05 09:05, Doug Hellmann wrote:
>>> 
>>> 
>>>> On Tue, Feb 4, 2014 at 5:14 PM, Ben Nemec <openstack at nemebean.com> wrote:
>>>> On 2014-01-08 12:14, Doug Hellmann wrote:
>>>> 
>>>> 
>>>> 
>>>>> On Wed, Jan 8, 2014 at 12:37 PM, Ben Nemec <openstack at nemebean.com> wrote:
>>>>>> On 2014-01-08 11:16, Sean Dague wrote:
>>>>>> On 01/08/2014 12:06 PM, Doug Hellmann wrote:
>>>>>> <snip>
>>>>>>> Yeah, that's what made me start thinking oslo.sphinx should be called
>>>>>>> something else.
>>>>>>> 
>>>>>>> Sean, how strongly do you feel about not installing oslo.sphinx in
>>>>>>> devstack? I see your point, I'm just looking for alternatives to the
>>>>>>> hassle of renaming oslo.sphinx.
>>>>>> 
>>>>>> Doing the git thing is definitely not the right thing. But I guess I got
>>>>>> lost somewhere along the way about what the actual problem is. Can
>>>>>> someone write that up concisely? With all the things that have been
>>>>>> tried/failed, why certain things fail, etc.
>>>>> The problem seems to be when we pip install -e oslo.config on the system, then pip install oslo.sphinx in a venv.  oslo.config is unavailable in the venv, apparently because the namespace package for o.s causes the egg-link for o.c to be ignored.  Pretty much every other combination I've tried (regular pip install of both, or pip install -e of both, regardless of where they are) works fine, but there seem to be other issues with all of the other options we've explored so far.
>>>>> 
>>>>> We can't remove the pip install -e of oslo.config because it has to be used for gating, and we can't pip install -e oslo.sphinx because it's not a runtime dep so it doesn't belong in the gate.  Changing the toplevel package for oslo.sphinx was also mentioned, but has obvious drawbacks too.
>>>>> 
>>>>> I think that about covers what I know so far.
>>>> Here's a link dstufft provided to the pip bug tracking this problem: https://github.com/pypa/pip/issues/3
>>>> Doug
>>>> This just bit me again trying to run unit tests against a fresh Nova tree.    I don't think it's just me either - Matt Riedemann said he has been disabling site-packages in tox.ini for local tox runs.  We really need to do _something_ about this, even if it's just disabling site-packages by default in tox.ini for the affected projects.  A different option would be nice, but based on our previous discussion I'm not sure we're going to find one.
>>>> Thoughts?
>>>  
>>> Is the problem isolated to oslo.sphinx? That is, do we end up with any configurations where we have 2 oslo libraries installed in different modes (development and "regular") where one of those 2 libraries is not oslo.sphinx? Because if the issue is really just oslo.sphinx, we can rename that to move it out of the namespace package.
>> 
>> oslo.sphinx is the only one that has triggered this for me so far.  I think it's less likely to happen with the others because they tend to be runtime dependencies so they get installed in devstack, whereas oslo.sphinx doesn't because it's a build dep (AIUI anyway).
> 
> That's pretty much what I expected.
> 
> Can we get a volunteer to work on renaming oslo.sphinx?
> 
> Doug
>  
>>>  
>>> Doug
>>>> -Ben
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140205/1048bd58/attachment.html>