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;
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
