Restructuring metadata 2.0 to leverage the extension model
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/2a4692ee5d1181fdbb8... 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 | ncoghlan@gmail.com | Brisbane, Australia
On 28 Nov 2013 23:18, "Nick Coghlan"
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/2a4692ee5d1181fdbb8...
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@gmail.com | Brisbane, Australia
participants (1)
-
Nick Coghlan