<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jan 21, 2016 at 1:31 AM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
</span>I think it's better to start with a small core that we *know* works,<br>
then expand later, rather than trying to make the first iteration too<br>
wide. The "manylinux1" tag itself is versioned (hence the "1" at the<br>
end), so "manylinux2" may simply have *more* libraries defined, rather<br>
than newer ones.<br>
<br>
The key is that we only have one chance to make a good first<br>
impression with binary Linux wheel support on PyPI, and we want that<br>
to be positive for everyone:<br>
<br>
* for publishers, going from "no Linux wheels" to "Linux wheels if you<br>
have few external dependencies beyond glibc" is a big step up (it's<br>
enough for a Cython accelerator module, for example, or a cffi wrapper<br>
around a bundled library)<br>
* for end users, we need to nigh certain that wheels built this way<br>
will *just work*<br></blockquote><div><br></div><div><br></div><div>In general, I see a tension between permissiveness and flexibility in the policy</div><div>here, with good arguments on both sides. A restrictive policy (like the one we</div><div>propose) will keep some wheels off PyPI that would work just fine on most</div><div>Linux boxes. But it will also ensure that fewer broken packages are uploaded.</div><div><br></div><div>In my opinion, the packaging system we have currently works pretty well.</div><div>Adopting a loose policy could therefore be experienced as a regression for</div><div>users who type ``pip install <package>` and receive a broken binary wheel.</div><div>This is one of the reasons we thought that it would be safest to start small</div><div>and work incrementally.</div><div><br></div><div>-Robert<br></div></div></div></div>