<html><body><p><tt>Robert Collins <robertc@...> writes:<br>>  - Linux vendors often unbundle urllib3 from requests and then apply<br>> what patches were needed to their urllib3; while not updating their<br>> requests package dependencies to reflect this.<br></tt><br><tt>I opened a bug on Fedora for them to update their requests package dependencies. See </tt><a href="https://bugzilla.redhat.com/show_bug.cgi?id=1253823"><tt>https://bugzilla.redhat.com/show_bug.cgi?id=1253823</tt></a><tt>. Of course that may continue to be an issue on older versions and other distros.</tt><br><br><tt>>  - if for any reason we have a distro-altered requests + a<br>> pip-installed urllib3, requests will [usually] break... see the 'not<br>> always released yet' key thing above.<br>> <br>> Now, there are lots of places this last thing can happen; they all<br>> depend on us having a dependency on requests that is compatible with<br>> the version installed by the distro, but a urllib3 dependency that<br>> triggers an upgrade of just urllib3. When constraints are in use, the<br>> requests version has to match the distro requests version exactly, but<br>> that will happen from time to time.<br></tt><br><tt>When you're using a distro, you're always going to have to worry about someone pip installing something that conflicts with the rpm, no? That could be for any reason, could be completely unrelated to OpenStack dependencies. Unless the distros have a way to put in protection against this, preventing pip install of something that is already installed by RPM?</tt><br><tt><br>>  - make sure none of our testing environments include distro <br>> requests packages.<br></tt><br><tt>It's not like requests is an unusual package for someone to have installed from their distro in a base OS image. So when they take that base OS and go to setup OpenStack, they'll be hitting this case, whether we tested it or not. So while not testing this case seems nice from a development perspective, it doesn't seem to fit real-world usage. I don't think it would make operators very happy.</tt><br><BR>
</body></html>