[Distutils] Restructuring metadata 2.0 to leverage the extension model

[Nick Coghlan]

On 28 Nov 2013 23:18, "Nick Coghlan" <ncoghlan at gmail.com> 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   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20131129/d1c1aaad/attachment.html>