<div dir="ltr">Hi Brett, Donald, and Nick,<br><div class="gmail_extra"><br></div><div class="gmail_extra">Thanks for your replies!</div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Mar 31, 2018 at 11:06 PM, 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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div><br></div></span><div>The main reason PyPI doesn't currently support distro specific wheels is because there isn't a compatibility tagging spec for them that's reasonable to use on a public index server - they currently end up being tagged as generic "linux" wheels. You can live with that on a private index server like the one that <a href="https://galaxyproject.org/" target="_blank">https://galaxyproject.org/</a> runs, but it would be incredibly confusing on PyPI.<br><br></div><div>As far as I know, <a href="https://mail.python.org/pipermail/distutils-sig/2015-July/026617.html" target="_blank">https://mail.python.org/<wbr>pipermail/distutils-sig/2015-<wbr>July/026617.html</a> is still the most complete write-up we have of a potential way to fix that, which is to:<br><br></div><div>1. extend the default Linux platform tag to include the ID and VERSION_ID fields from /etc/os-release (credit to Galaxy Project's Nate Coraor for that core concept)<br></div><div>2. define a config file under /etc/python/ that distros can use to change both the build tag (e.g. allowing CentOS users to emit RHEL compatible wheels, or Ubuntu users to emit Debian compatible ones), and a list of binary compatible distro tags (e.g. allowing CentOS to consume RHEL tagged wheels, Ubuntu to consume Debian tagged wheels, and other musl based distros to consume Alpine tagged wheels)<br></div><div>3. define an equivalent per-virtualenv file to override the settings from (2)<br></div><div>4. update pip/setuptools/twine/<wbr>warehouse/etc to account for the new compatibility tag variant<br><br></div><div>One useful aspect here is that older clients will just ignored the new tags as "not a match", which means there shouldn't be any significant backwards compatibility hurdles.</div><span class=""><div><br></div></span></div>Honestly, I think the main benefit of heading down this road will be to allow folks to cache their custom wheel builds more effectively, so I'm not especially worried about making it generic (beyond the platform level config file suggested above).<br><br>That said, if there were to be a significant growth in non-manylinux Linux wheels on PyPI, I'd expect them to be for the official Docker Inc base Python images, which are Alpine based, and hence can't use the glibc-based manylinux binaries.<br></div></div></blockquote><div><br></div><div>I think this is a good idea, especially given that manylinux1 and manylinux2010 wheels won't work on the official Docker image for Python. What does everyone else think?</div><div><br></div><div>If we wanted to contribute towards this effort, how can the community help, Nick?</div><div><br></div><div>Thanks,</div><div>Trishank</div></div></div></div>