On 2014-02-05 10:58, Doug Hellmann wrote:
> On Wed, Feb 5, 2014 at 11:44 AM, Ben Nemec <openst...@nemebean.com> wrote: > > On 2014-02-05 09:05, Doug Hellmann wrote: > > On Tue, Feb 4, 2014 at 5:14 PM, Ben Nemec <openst...@nemebean.com> wrote: > > On 2014-01-08 12:14, Doug Hellmann wrote: > > On Wed, Jan 8, 2014 at 12:37 PM, Ben Nemec <openst...@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 [1] 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? I'm winding down on the parallel testing work so I could look at this next. I don't know exactly what is going to be involved in the rename though. We also need to decide what we're going to call it. I haven't come up with any suggestions that I'm particularly in love with so far. :-/ -Ben > Doug > > Doug > > -Ben Links: ------ [1] https://github.com/pypa/pip/issues/3
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
