<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Oct 20, 2017 at 4:32 PM, Doug Hellmann <span dir="ltr"><<a href="mailto:doug@doughellmann.com" target="_blank">doug@doughellmann.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Excerpts from Clark Boylan's message of 2017-10-20 13:14:13 -0700:<br>
<div><div class="gmail-h5">> On Fri, Oct 20, 2017, at 11:17 AM, Clark Boylan wrote:<br>
> > On Fri, Oct 20, 2017, at 07:23 AM, Doug Hellmann wrote:<br>
> > > It sounds like the PyPI/PyPA folks are planning some major changes to<br>
> > > pip internals, soon.<br>
> > ><br>
> > > I know pbr uses setuptools, and I don't think it uses pip, but if<br>
> > > someone has time to verify that it would be helpful.<br>
> > ><br>
> > > We'll also want to watch out for breakage in normal use of pip 10. If<br>
> > > they're making changes this big, they may miss something in their own<br>
> > > test coverage that affects our jobs.<br>
> > ><br>
> ><br>
> > After a quick skim of PBR I don't think we use pip internals anywhere.<br>
> > Its all executed via the command itself. That said we should test this<br>
> > so I've put up <a href="https://review.openstack.org/513825" rel="noreferrer" target="_blank">https://review.openstack.org/<wbr>513825</a> (others should feel<br>
> > free to iterate on it if it doesn't work) to install latest pip master<br>
> > in a devstack run.<br>
><br>
> The current issue this change is facing can be seen at<br>
> <a href="http://logs.openstack.org/25/513825/4/check/legacy-tempest-dsvm-py35/c31deb2/logs/devstacklog.txt.gz#_2017-10-20_20_07_54_838" rel="noreferrer" target="_blank">http://logs.openstack.org/25/<wbr>513825/4/check/legacy-tempest-<wbr>dsvm-py35/c31deb2/logs/<wbr>devstacklog.txt.gz#_2017-10-<wbr>20_20_07_54_838</a>.<br>
> The tl;dr is that for distutils installed packages (basically all the<br>
> distro installed python packges) pip refuses to uninstall them in order<br>
> to perform upgrades because it can't reliably determine where all the<br>
> files are. I think this is a new pip 10 behavior.<br>
><br>
> In the general case I think this means we can not rely on global pip<br>
> installs anymore. This may be a good thing to bring up with upstream<br>
> PyPA as I expect it will break a lot of people in a lot of places (it<br>
> will break infra for example too).<br>
><br>
> Clark<br>
><br>
<br>
</div></div>Yes, it would be good for someone who understands the cases where we're<br>
doing these sorts of global package installations using pip to post on<br>
distutils-sig explaining the breakage and asking for some time to let us<br>
work around the issue.<br>
<br>
We have a couple of ways to mitigate it, depending on the situation.<br>
<br>
1. Pin the affected packages to the system package versions in our<br>
   constraints list.<br>
<br>
2. Install into a virtualenv that ignores system packages, avoiding the<br>
   need to upgrade at all.<br>
<br>
3. Remove the system package before installing from pip (why is it there<br>
   in the first place?).<br>
<br>
It's not clear to me which is the best approach.  I've added<br>
[devstack][qa] to the subject line to draw some more attention to<br>
this thread from folks familiar with these jobs.<br>
<span class="gmail-HOEnZb"><font color="#888888"><br>
Doug<br>
</font></span><div class="gmail-HOEnZb"><div class="gmail-h5"><br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">I have used option 2 with great success to avoid the issue of system package conflicts for a couple of years now, back when pip would still uninstall system packages for upgrades.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Option 3 is difficult to make work since so many packages have dependancies on python-* packages, I abandoned that approach fairly quickly.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Thanks,</div><div class="gmail_extra">SamYaple<br></div><div class="gmail_extra"><br></div></div>