[Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

[Nick Coghlan]

On 10 October 2015 at 04:47, Chris Barker <chris.barker at noaa.gov> wrote:
> So the question is: if I compile my third party package against numpy and
> mkl, it would depend on numpy and py_mkl.
>
> If I went to installed this on a system that had a numpy that depends on
> openblas, pip would install py_mkl (having already installed numpy and
> py_openblas). And I'd have a numpy extension calling into a different BLAS
> than numpy itself is calling into -- would that cause any problems? Python
> would be linked to two libs with the same names -- would that cause
> conflict? I'm way out of my depth here!

Yes, you'd get weird binary ABI problems in that situation. There's a
reason centrally built Linux distros and cross-platform distros like
conda exist - we pick the common ABIs that all the components we build
use, and enforce them in the build system.

For "built by anyone" ABIs, the best you can hope for is to
detect-and-report fundamental conflicts, as you can't solve the
general case.

The approach I proposed for metadata 2.0 is introducing an
environmental constraints extension that caused things to fail at
install time if the installer detected a binary incompatibility:
https://www.python.org/dev/peps/pep-0459/#the-python-constraints-extension

The equivalent in a pre-metadata 2.0 world would be yet-another-file
in the dist-info directory.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia