[Distutils] Deferring metadata hooks

Nick Coghlan ncoghlan at gmail.com
Sun Mar 2 08:25:43 CET 2014

I've just posted updated versions of PEP 426 and 459 that defer the
"metadata hooks" feature. The design and behaviour of that extension
is still way too speculative for me to approve in its current form,
but I also don't want to hold up the rest of the changes in metadata
2.0 while we thrash out the details of a hook system.

That said, I still don't want us to get into a situation where someone
later publishes a wheel file that expects metadata hook support and
older tools silently install it without running the hooks.

Accordingly, the revised PEP 426 adds a single simpler feature to the
extensions system: the idea of a "required extension".

If a project sets that flag for an extension (by including
"required_extension": true in the extension metadata), and an
installation tool doesn't understand it, then the tool is required to
either fail the installation attempt entirely or else fall back to
installing from source.

That way, project authors will be able to distinguish between "these
metadata hooks are just an optimisation, things will still work if you
don't run them" and "if you don't run these hooks, your installation
will be broken".

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.


P.S. The draft PEP for metadata hooks is still available at

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

More information about the Distutils-SIG mailing list