On 10 October 2015 at 04:47, Chris Barker <chris.bar...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
