On 1 November 2017 at 02:23, Wes Turner
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@gmail.com | Brisbane, Australia