<div dir="ltr"><div dir="ltr">On Mon, Sep 9, 2019 at 5:40 PM Peter Penchev <<a href="mailto:pp@storpool.com">pp@storpool.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Mon, Sep 9, 2019 at 2:55 PM Sean Mooney <<a href="mailto:smooney@redhat.com" target="_blank">smooney@redhat.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, 2019-09-09 at 11:22 +0300, Peter Penchev wrote:<br>
> Hi,<br>
> <br>
> When devstack's `setup_dev_lib` function is invoked and USE_PYTHON3 has<br>
> been specified, this function tries to also install the development library<br>
> for Python 2.x, I guess just in case some package has not declared proper<br>
> Python 3 support or something. It then proceeds to install the Python 3<br>
> version of the library and all its dependencies.<br>
> <br>
> Unfortunately there is a problem with that, and specifically with script<br>
> files installed in the system's executable files directory, e.g.<br>
> /usr/local/bin. The problem appears when some Python library has already<br>
> been installed for Python 3 (and has installed its script files), but is<br>
> now installed for Python 2 (overwriting the script files) and is then not<br>
> forcefully reinstalled for Python 3, since it is already present. Thus, the<br>
> script files are last modified by the Python 2 library installation and<br>
> they have a hashbang line saying `python2.x` - so if something then tries<br>
> to execute them, they will run and use modules and libraries for Python 2<br>
> only.<br>
yes this is a long standing issue. we discovered it a year ago but it was never fix.<br>
<br>
in Ussrui i guess one of the first changes to devstack  to make it python 3 only<br>
will be to chagne that behavior. im not sure if we will be able to change it before then.<br>
<br>
whenever you us libs_from_git in your local.conf on a python 3 install it will install<br>
them twice both with python 2 and python 3.  i hope more distros elect to symlink /usr/bin/python to python 3<br>
some distros have chosen to do that on systems that are python only and i believe that is the correct<br>
approch.<br>
<br>
when i encountered this it was always resuliting on the script header being #!/usr/bin/python  with no<br>
version suffix i<br>
gues on a system where that points to python 3 the python 2.7 install might write python2.7<br>
there instead?<br></blockquote><div><br></div><div>It depends on what version of pip is invoked; I think that the way devstack invokes it nowadays it will always provide a version on the shebang line.<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>
> <br>
> We experienced this problem when running the cinderlib tests from Cinder's<br>
> `playbooks/cinderlib-run.yaml` file - it finds a unit2 executable<br>
> (installed by the unittest2 library) and runs it, hoping that unit2 will be<br>
> able to discover and collect the cinderlib tests and load the cinderlib<br>
> modules. However, since unittest2 has last been installed as a Python 2<br>
> library, unit2 runs with Python 2 and fails to locate the cinderlib<br>
> modules. (Yes, we know that there are other ways to run the cinderlib<br>
> tests; this message is about the problem exposed by this way of running<br>
> them)<br>
> <br>
> The obvious solution would be to instruct the Python 2 pip to not install<br>
> script (or other shared) files at all; unfortunately,<br>
> <a href="https://github.com/pypa/pip/issues/3980" rel="noreferrer" target="_blank">https://github.com/pypa/pip/issues/3980</a> ("Option to exclude scripts on<br>
> install"), detailing a very similar use case ("need it installed for Python<br>
> 2, but want to use it with Python 3") has been open for almost exactly<br>
> three years now with no progress. I wonder if I could try to help, but even<br>
> if this issue is resolved, there will be some time before OpenStack can<br>
> actually depend on a recent enough version of pip.<br>
well the obvious solution is to stop doing this entirly.<br>
it was added as a hack to ensure if you use  LIB_FROM_GIT in you local.conf that those<br>
libs would always be install from the git checkout that you specified in you local.conf<br>
for train we are technically requireing all project to run under python 3 so we could remove<br>
the fallback mechanium of in stalling under python 2. it was there incase a service installed<br>
under python 2 to ensure it used the same version of the lib and did not use a version form<br>
pypi instead. i wanted to stop doing this last year but we could not becase not all project<br>
could run under python 3. but now that they should be able to we dont need this hack anymore.<br>
we should change it to respec the python version you have selected. that will speed<br>
up stacking speed as we wont have to install everything twice and fix the issue you have encountered.<br></blockquote><div><br></div><div>Yeah, thanks for confirming my thoughts that this might be the right solution. I've proposed <a href="https://review.opendev.org/681029/" target="_blank">https://review.opendev.org/681029/</a> (and set workflow -1) to wait for the Ussuri cycle.<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>
> A horrible workaround would be to find the binary directory before<br>
> installing the Python 2 library (using something like `pip3.7 show<br>
> somepackage` and then running some heuristics on the "Location" field),<br>
> tar'ing it up and then restoring it... but I don't know if I even want to<br>
> think about this.<br>
> <br>
> Another possible way forward would be to consider whether we still want the<br>
> Python 2 libraries installed - is OpenStack's Python 3 transition reached a<br>
> far enough stage to assume that any projects that still require Python 2<br>
> *and* fail to declare their Python 2 dependencies properly are buggy? To be<br>
> honest, this seems the most reasonable path for me - drop the "also install<br>
> the Python 2 libs" code and see what happens. I could try to make this<br>
> change in a couple of test runs in our third-party Cinder CI system and see<br>
> if something breaks.<br></blockquote><div><br></div><div>G'luck,</div><div>Peter</div><div><br></div></div></div></blockquote><div>Argh, I sent this from the wrong account, did I not...</div><div><br></div><div>G'luck,</div><div>Peter</div><div><br></div></div></div>