<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 31, 2020 at 4:32 AM Ian Wienand <<a href="mailto:iwienand@redhat.com">iwienand@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, Jul 03, 2020 at 12:13:04PM -0700, Clark Boylan wrote:<br>
> Setuptools has made a new version 48 release. This appears to be<br>
> causing problems for devstack because `pip install -e $PACKAGE_PATH`<br>
> installs commands to /usr/bin and not /usr/local/bin on Ubuntu as it<br>
> did in the past. `pip install $PACKAGE_PATH` continues to install to<br>
> /usr/local/bin as expected. Devstack is failing because<br>
> keystone-manage cannot currently be found at the specific<br>
> /usr/local/bin/ path.<br>
<br>
This is now back with setuptools 50.0.0 [1], see the original issue<br>
[2].<br>
<br>
The problems are limited to instances where jobs are installing with<br>
pip as root into the system environment on platforms that override the<br>
default install path (debuntu).  The confluence of this set of<br>
requirements of neatly describes most devstack testing :/<br>
<br>
There's two visible problems; both stem from the same issue.  Packaged<br>
Debuntu python installs things into dist-packages; leaving<br>
site-packages for a non-packaged interpreter, should you wish to<br>
install such a thing.  It patches distutils to provide this behaviour.<br>
The other thing it does is makes pip installs use /usr/local/bin,<br>
rather that /usr/bin.<br>
<br>
Thus it is unfortunately not just s,/usr/local/bin,/usr/bin,g because<br>
the new setuptools will install all the libraries into site-packages;<br>
which the packaged python intpreter doesn't know to look for.<br>
<br>
Using SETUPTOOLS_USE_DISTUTILS=stdlib with such installs is one<br>
option; it feels like it just makes for more confusing bifurcation.<br>
We can't really set this in stack.sh as a global, because we wouldn't<br>
want this to apply to subshells that are installing in virtualenv's,<br>
for example.  It might be the best option.<br>
<br>
A more radical thought; perhaps we could install a non-packaged python<br>
interpreter for devstack runs.  Isolation from packaging cuts both<br>
ways; while we might work around packaging issues in CI, we're also<br>
working around packaging issues that then just hit you when you're in<br>
production.  The eternal question of "what are we testing".<br>
<br>
I don't think there's an easy answer.  Which is probably why we've<br>
ended up here with everything broken ...<br></blockquote><div><br></div><div>Is it the right time to discuss switching to virtual environments? We've had quite a positive experience with bifrost since we stopped trying global installations at all.</div><div><br></div><div>Dmitry<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
-i<br>
<br>
[1] <a href="https://github.com/pypa/setuptools/commit/04e3df22df840c6bb244e9b27bc56750c44b7c85" rel="noreferrer" target="_blank">https://github.com/pypa/setuptools/commit/04e3df22df840c6bb244e9b27bc56750c44b7c85</a><br>
[2] <a href="https://github.com/pypa/setuptools/issues/2232" rel="noreferrer" target="_blank">https://github.com/pypa/setuptools/issues/2232</a><br>
<br>
<br>
</blockquote></div></div>