[Distutils] [Python-ideas] Add processor generation to wheel metadata

[Nick Coghlan]

On 1 November 2017 at 02:23, Wes Turner <wes.turner at gmail.com> wrote:

> Maybe the anaconda team has some insight on a standard way to capture (&
> configure) compiler versions and flags in package metadata?


The short answer is "You don't, and instead live with the related
uncertainty". Similar to Linux distro packages, these expectations are set
by the build environment, and it's up to whoever's publishing a conda
channel to make sure all the packages it contains are consistent both with
each other, and with 3rd party wheel files (if they want to support layered
applications which mix third party wheel files with platform provided
binaries).

https://reproducible-builds.org/docs/perimeter/ discusses some of the
aspects of a system that may or may not affect a build process, and hence
the ABI compatibility of a result. There unfortunately isn't a generic way
of knowing which CPU flags are actually going to be important in
determining a project's ABI or its platform requirements (e.g. CPython's
independence of SSE2 doesn't arise from specific choice - it arises from
the fact that there isn't any code in CPython that relies on CPU provided
vector operations).

In the PEP 426/459 draft, my proposal was to have an optional extension to
the metadata called "python.constraints" that allowed projects to declare
particular compatibility constraints on their installation environments:
https://www.python.org/dev/peps/pep-0459/#the-python-constraints-extension

That way, an installer could download a wheel file, check if its usage
constraints were met, and if not, fall back to building from source. That
still seems like a reasonable way to go to me, although we may want to look
at defining it as a separate JSON file stored in dist-info (similar to
entry_points.txt), rather than tying it to a new version of the main
metadata spec.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20171101/dc3890bc/attachment-0001.html>