[Distutils] Deferring metadata hooks

Oscar Benjamin oscar.j.benjamin at gmail.com
Sun Mar 2 22:36:09 CET 2014

On 2 March 2014 21:05, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> >
>> > I think this approach may also encourage a design where projects do
>> > something sensible *by default* (e.g. NumPy defaulting to SSE2) and
>> > then use the (not yet defined) post-installation hooks to potentially
>> > *change away* from the default to something more optimised for that
>> > particular system (e.g. NumPy overwriting itself with an SSE3
>> > version), while still *allowing* developers to refuse to let the
>> > software install if the metadata hooks won't be run.
>> I'm not sure but there does seem to be some discussion and movement
>> toward the idea of numpy distributing openblas binaries (which would
>> solve the SSE problem). See the threads starting here for more:
>> http://mail.scipy.org/pipermail/numpy-discussion/2014-February/069186.html
>> http://mail.scipy.org/pipermail/numpy-discussion/2014-February/069106.html
>> (Note that shipping openblas binaries does not solve the ABI mismatch
>> problems that compatibility tags could address).
> So long as NumPy defines and publishes an extension with the relevant
> details in its metadata, the metadata constraints extension would eventually
> be able to automate consistency checks.
> However, I'm starting to think you may be right and it will be worth having
> that defined from the beginning, specifically to help ensure we keep the
> NumPy dependent wheels on PyPI consistent with each other.

I expect that those involved in distributing wheels for the scipy
stack would coordinate and quickly converge on a consistent set of
wheels for Windows/OSX on PyPI so I doubt that it would be an issue in
that sense.

Where it is an issue is for people who install different pieces from
different places i.e. mixing source builds, .exe installers, wheels
from PyPI, and perhaps even conda packages and wheels from other
places. If a mechanism was provided to prevent borken installs and
give helpful error messages I'm sure it would be taken advantage of.

If it were also possible to upload and select between multiple
variants of a distribution then that might lower the bar for numpy to
distribute e.g. openblas wheels. A user who was unhappy with openblas
could just as easily install an alternative. (Changing BLAS library is
a big deal for numpy).


More information about the Distutils-SIG mailing list