On 28 Nov 2013 23:18, "Nick Coghlan" <[email protected]> wrote: > > 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.
Something that *isn't* in this model yet is a requirement resolution hook to allow system package managers to intercept (and potentially resolve) package installation and removal requests in the system Python, while leaving virtual environments alone. That's definitely just a wish list item though - even if we can't figure out a nicer way to handle that, we're still no worse off than we are now. Cheers, Nick. > > Cheers, > Nick. > > -- > Nick Coghlan | [email protected] | Brisbane, Australia
_______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
