[Distutils] Changing the "install hooks" mechanism for PEP 426

Vinay Sajip vinay_sajip at yahoo.co.uk
Thu Aug 15 18:06:53 CEST 2013

Nick Coghlan <ncoghlan <at> gmail.com> writes:

> Sounds fair - let's use "pydist", since we want these definitions to be
> somewhat independent of their reference implementation in distlib :)

Seems reasonable.

> Based on PJE's feedback, I'm also starting to think that the
> exports/extensions split is artificial and we should drop it. Instead,
> there should be a "validate" export hook that build tools can call to
> check for export validity, and the contents of an export group be
> permitted to be arbitrary JSON.

I don't know that we should allow arbitrary JSON here: I would wait to see 
what it is we need, and keep it restricted for now until the more detailed 
understanding of those needs becomes more apparent. Arbitrary JSON is likely 
to be needed for *implementations* of things, but not necessarily for 
*interfaces* between things. The PEP 426 scope should be mainly focused on 
dependency resolution, other installer requirements and interactions between 
installed distributions (exports).

> The installers are still going to have to be export_hooks aware, though,
> since the registered handlers are how the whole export system will be
> bootstrapped. 

Distil currently supports the preuninstall/postinstall hooks, and I expect 
to extend this to other types of hook.

> Something else I'm wondering: should the metabuild system be separate,

I think it should be separate, though of course there will be a role for 
exports. The JSON metadata needed for source packaging and building can be 
quite large (example at [1]), and IMO doesn't really belong with the PEP 426 
metadata. Currently, the extended metadata used by distil for building 
contains the whole PEP 426 metadata as an "index-metadata" sub-dictionary. 
It's already a fairly generic build system - though simple, it can build 
e.g. C/C++/Fortran extensions, handle Cython, SWIG and so on, without using 
any of distutils. However, there's still lots of work to be done to 
generalise the interfaces between different parts of the system so that 
building can be plug and play - it's a bit opaque at the moment, but I 
expect that will improve.


Vinay Sajip

[1] http://red-dove.com/pypi/projects/A/Assimulo/package-2.2.json

More information about the Distutils-SIG mailing list