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

[Ivan Pozdeev]

On 01.11.2017 7:33, Nick Coghlan wrote:
> 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
There's no such thing as "a set of compiler flags that unequivocally 
defines ABI." Any proprocessor macro that changes a type or a 
subroutine's signature will result in an incompatibility, too. So, "ABI" 
can only be defined on a case by case basis.
> (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).
CPython is compiled with the corresponding /arch and doesn't use SSE2 
intrinsics (I did check that cl.exe doesn't trigger an error on the 
latter even with lower /arch). That's enough to guarantee the 
instruction set that it uses. So, I don't see a problem here.
> 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.
Having to download a wheel just to check compatibility is a deal 
breaker. There are dozens of them for a given package (pip examines old 
versions, too), and each one can weigh quite a bit. With more flavors to 
add, the number will multiply. Metadata required to check if the wheel 
is suitable for install must be available separately from its contents.

Currently, pip examines the triplets in package names.
What I'm suggesting is to put/append something more specific than 
"win32" into it when applicable.

> 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
I checked it out.
It's not applicable here for the aforementioned reason, and one more thing.

A package's file name should be unique - to easily distinguish it from 
others. The _one obviouls way_(tm) is to make it contain all the 
metadata fields that distinguish this package from others.

I mean, you _can_ make metadata available otherwise (with some API, in a 
small companion file etc.) -- but that'd be suboptimal to simply a 
meaningful file name that will go with this file wherever it goes.
(For an illustration why this is an anti-pattern, you can check out a 
WSUS server contents -- that's an epitome of meaningless filenames, you 
can't know anything about a file without a database query. Not only is 
that grossly inconvenient; if the database goes under, the entire 
multigigabyte storage becomes useless.)

-- 
Regards,
Ivan;

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20171108/6602c631/attachment.html>