
<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Sep 17, 2014, at 10:24 PM, Thomas Goirand <<a href="mailto:zigo@debian.org" class="">zigo@debian.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">On 09/18/2014 08:22 AM, Morgan Fainberg wrote:<br class=""><blockquote type="cite" class="">I think that all of the conversation to this point has been valuable,<br class="">the general consensus is vendoring a library is not as desirable as<br class="">using it strictly as a dependency. It would be nice in a perfect<br class="">world if vendoring wasn’t and issue, but in this case I think the<br class="">root of the matter is that Debian un-vendors urllib3 and we have<br class="">referenced the vendored urllib3 instead of installing and utilizing<br class="">urllib3 directly.<br class=""><br class="">This poses at least one problem for us: we are not able to guarantee<br class="">we’re using the same urllib3 library as requests is. I am unsure how<br class="">big of a deal this ends up being, but it is a concern and has brought<br class="">up a question of how to handle this in the most appropriate and<br class="">consistent way across all of the distributions we as OpenStack support. <br class=""><br class="">Does this make requests a bad library we should toss aside for<br class="">something else? Instead of being concerned with the reasons for<br class="">vendoring urllib3 (or un-vendoring it) we should shift the conversation<br class="">towards two questions:<br class=""><br class="">1. Is it a real issue if the version of urllib3 is mismatched between<br class="">our client libraries and requests? <br class="">2. If it is a real issue how are we solving it?<br class=""></blockquote><br class="">The main issue is that urllib3 in requests, as other pointed out, is not<br class="">up-to-date, and will not be updated. In fact, that's the main reason why<br class="">the upstream authors of requests are vendorizing: it's because they<br class="">don't want to carry the burden of staying up-to-date.<br class=""></div></blockquote><div><br class=""></div><div>I don’t think this is remotely true, often times requests updates itself</div><div>to versions of urllib3 which aren’t even released yet. Sometimes urllib3</div><div>might make commits and do a release that happens between requests</div><div>versions though. I mean technically they might be not up to date until</div><div>their next version release though.</div><br class=""><blockquote type="cite" class=""><div class=""><br class="">And then, there's incompatibilities and divergences that appear, leading<br class="">to all sorts of unexpected issues, like one thing working with pip, but<br class="">not with the packages. This kind of issues are very hard to understand<br class="">and debug. Distributions may report the issue upstream, then upstream<br class="">will say "but it's working for me", and then we may loose a lot of time.<br class="">This happened already, and may happen again if we don't care enough.<br class=""></div></blockquote><div><br class=""></div><div>I think this is bound to happen anytime you have downstream modifying</div><div>things. It happens in pip (pip vendors things too) and yea it’s quite annoying</div><div>but part of PEP 440 is providing ways for downstream to signal they’ve</div><div>modified things so that instead of “foo 1.0” you have “foo 1.0+ubuntu1” or</div><div>whatever.</div><br class=""><blockquote type="cite" class=""><div class=""><br class=""><blockquote type="cite" class="">Obviously we can work with the requests team to figure out the best<br class="">approach.<br class=""></blockquote><br class="">There's only a single approach that works: have the requests upstream<br class="">authors to stop embedding foreign code, and use the dependency instead.<br class=""></div></blockquote><div><br class=""></div><div>There are legitimate reasons for a project to vendor things. Linux distributions</div><div>are not the end be all of distribution models and they don’t get to dictate to</div><div>upstream.</div><div><br class=""></div><div>Generally I agree that requests should not vendor urllib3, but it’s not a clear</div><div>cut thing where there is one right way to do it.</div><br class=""><blockquote type="cite" class=""><div class=""><br class=""><blockquote type="cite" class="">We should focus on the solution here rather than continuing<br class="">down the path of whether requests should/shouldn’t be vendoring it’s<br class="">dependencies since it is clear that the team has their reasons and<br class="">does not want to switch to the dependency model again.<br class=""></blockquote><br class="">I'm sure they have tons of wrong reasons. If they don't want to change<br class="">anything, then we can only try to work around the issue, and never use<br class="">the embedded version.<br class=""></div></blockquote><br class=""></div><div>Generally you either work with the embedded versions or you don’t</div><div>use requests. You’re going to get very strange incompatibility problems</div><div>if you try to mis requests.packages.urllib3 and urllib3 in one codebase</div><div>and if you’re using requests at all it’s going to be expecting to use</div><div>the embedded copy of urllib3.</div><br class=""><div class="">

<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">---</div><div class="">Donald Stufft</div><div class="">PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA</div></div></div>

</div>

<br class=""></body></html>