[Python-Dev] Edits to Metadata 1.2 to add extras (optional dependencies)

Nick Coghlan ncoghlan at gmail.com
Tue Aug 28 14:59:55 CEST 2012


On Tue, Aug 28, 2012 at 10:33 PM, Daniel Holth <dholth at gmail.com> wrote:
> Wheel deals with this somewhat by including a
>
> Packager: bdist_wheel
>
> line in WHEEL so that you can deal with packager-specific bugs.

Right, but the problem with that is it's defining a couple of *new*
namespaces to manage:
- the filenames within dist_info (although uppercasing a PyPI project
name is pretty safe)
- the "Packager" field (bdist_wheel is a distutils command rather than
a PyPI project)

By using PyPI distribution names to indicate custom sections in the
main metadata file, we would get to exploit an existing registry that
enforces uniqueness without imposing significant overhead.

> Bento uses indentation so you can have sections:
>
> Key: value
>    Indented Key: value

Yes, the main metadata file could definitely go that way. The three
main ways I can see an extensible metadata format working are:

1. The way wheel currently works (separate WHEEL file, naming
conflicts resolved largely by first-in-first-served with no official
registry, no obvious indication which project defines the format)

2. PyPI as extension registry, with an ini-file inspired section
syntax inside dist-info/METADATA

    <standard metadata must appear first>

    [wheel]
    Version: 0.9
    Packager: bdist_wheel-0.1
    Root-Is-Purelib: true

3. PyPI as extension registry, with an indented section syntax inside
dist-info/METADATA

    <custom metadata sections may appear anywhere in the file>


    Extended-Metadata: wheel
        Version: 0.9
        Packager: bdist_wheel-0.1
        Root-Is-Purelib: true

My preference is currently for the ini-style variant, but I could
definitely live with the indented approach.Either way, any project
registered on PyPI would be free to add their own extensions without
fear of naming conflicts or any doubts about the relevant authority
for the meaning of the fields. Standard tools could just treat those
sections as opaque blocks of text to be preserved verbatim, or else
they could be constrained so that the standard tools could pick out
the individual key:value pairs.

Namespacing an extension mechanism based on PyPI distributions names
should be pretty straightforward and it will mean that a lot of
problems that can otherwise arise with extensible metadata systems
should simply never come up.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia


More information about the Python-Dev mailing list