It's (very) early days at this point, but I've taken the first steps towards breaking up the metadata 2.0 monolith into multiple relatively independent metadata extensions:
https://bitbucket.org/pypa/pypi-metadata-formats/commits/2a4692ee5d1181fdbb8008318c2a1aea7f14a0f8 Finalising metadata 2.0 is still in the "post CPython 3.4, leading up to pip 1.6" time frame, but with 3.4 hitting feature freeze last weekend with a mostly integrated pip, I figured it was time to share at least something about my current plans for this, even if it's another few months before I update it again. The general aim is that the stuff that was previously identified as the "essential dependency metadata" will be all that remains directly defined in PEP 426, with everything else moved out to metadata extensions. A couple of other notable transitions started in this commit: - install_hooks are out, metadata_hooks are in (as an extension). The general idea is that you can register an interest in export groups and other extensions, and installation tools will invoke your hooks at the appropriate time. Still a lot of details to be worked out, but I already like it much better than the previous install_hook model. - started adding a formal notion of an "integrator suffix" to the versioning PEP. This is a matter of recognising the fact that redistributors will often apply additional patches to their redistributed version, while still aiming to preserve the API and most of the behaviour of the upstream release. One key advantage of this model is that I'm proposing for the extensions to be independently versioned, so we'd only have to update the main metadata PEP in order to change the essential dependency resolution metadata. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
