[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.
Regards,
Vinay Sajip
[1] http://red-dove.com/pypi/projects/A/Assimulo/package-2.2.json
More information about the Distutils-SIG
mailing list