<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Hello Nick,</div><div class="gmail_quote"><br></div><div class="gmail_quote">On Tue, Apr 3, 2018 at 7:59 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 class=""><br>
</span>At the specification level, we'll need an update to PEP 425 that's<br>
comparable to Dustin's PEP 566 for the core metadata (which both<br>
defined metadata 2.1, and made<br>
<a href="https://packaging.python.org/specifications/core-metadata/" rel="noreferrer" target="_blank">https://packaging.python.org/<wbr>specifications/core-metadata/</a> the stable<br>
reference URL for the latest version of the metadata spec).<br>
<br>
I'd like to see us do the same thing for platform compatibility tags:<br>
have <a href="https://packaging.python.org/specifications/platform-compatibility-tags/" rel="noreferrer" target="_blank">https://packaging.python.org/<wbr>specifications/platform-<wbr>compatibility-tags/</a><br>
define the format, and use the PEP process to make changes to that<br>
living spec.<br>
<br>
While the primary motivating use case is distro-specific Linux wheels,<br>
we should at least consider the possibility of defining the new<br>
optional fields in compatibility tags in such a way that they could<br>
also be used for ABI compatibility levels in more centrally controlled<br>
platforms (i.e. Windows, macOS, iOS, Android), or to tag an expected<br>
deployment environment (e.g. letting the Galaxy Project folks mark all<br>
their internal wheels as "galaxyproject", and then configure their<br>
deployment environments to only accept wheels tagged that way).<br>
<br>
Such a spec update would cover points 1->3 above.<br>
<br>
At the implementation level, I don't have any great insight on how you<br>
might best go about pursuing that, but I suspect factoring out some<br>
useful helper functions into the low level `packaging` library may<br>
make sense (I believe Vinay Sajip's `distlib` already has some helpers<br>
along these lines that would potentially require updates). At a<br>
minimum, to be useful:<br>
<br>
* either setuptools+bdist_wheel need to be able to produce wheels with<br>
the more detailed tags, or else there has be a suitable wheel renaming<br>
utility available (akin to `auditwheel repair`)<br>
* twine needs to be able to upload wheels with the more detailed tags<br>
* warehouse needs to be able to accept uploads with the more detailed tags<br>
<br>
(For that last point, I'd personally prefer it to be a project level<br>
setting to opt-in to allowing uploads with the more detailed tags,<br>
such that the default behaviour is to reject them, and provide an<br>
opportunity for us to nudge folks towards manylinux wheels)</blockquote><div><br></div><div>Sounds good. I'll take a stab at updating the PEP, and see. Can't make any promises as to a timeline, but I'll get back when (and if) I have a draft!</div><div><br></div><div>Regards,</div><div>Trishank</div></div></div></div>