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

[Daniel Holth]

On Tue, Aug 28, 2012 at 8:28 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Tue, Aug 28, 2012 at 10:07 PM, Donald Stufft <donald.stufft at gmail.com> wrote:
>> I personally think that at a minimum we should have X-Fields that
>> get moved into the normal METADATA file, and personally I would
>> prefer to just drop the X- prefix completely.
>
> Hell no. We've been down this road with setuptools and it *sucks*.
> Everybody gets confused, because you can't tell just by looking at a
> metadata file what's part of the standard and what's been added just
> because a tool developer thought it was a good idea without being able
> to obtain broad consensus (perhaps because others couldn't see the
> point until the extension had been field tested for an extended
> period).
>
> Almost *nobody* reads metadata specs other than the people that helped
> write them. Everyone else copies a file that works, and tweaks it to
> suit, or they use a tool that generates the metadata for them based on
> some other interface.
>
> The least-awful widespread extension approach I'm aware of is CSS
> vendor prefixes. X- headers suck because they only give you two
> namespaces - the "standard" namespace and the "extension" namespace.
> That means everyone is quickly forced back into seeking agreement and
> consensus to avoid naming conflicts for extension fields.
>
> However, I'm open to the idea of a properly namespaced extension
> mechanism, which is exactly why I suggested separate files flagged in
> the main metadata with the PyPI project that defines the format of
> those extensions. I'm also open to the idea of extensions appearing in
> [PyPI distribution] prefixed sections after the standard metadata so,
> for example, there could be a [wheel] section in METADATA rather than
> a separate WHEEL file.
>
> We already have a namespace registry in the form of PyPI, so there's
> no reason to invent a new one, and allowing *any* PyPI distribution to
> add custom metadata fields without name conflicts would allow easy
> experimentation while still making it clear which fields are defined
> in PEPs and which are defined by particular projects.
>
>
>> I know that distutils2 have requires-dist, but for the sake of
>> argument pretend they don't. If there is first class support for
>> extending the metadata with new fields, a project could come
>> along, and add a requires-dist (or x-requires-dist) concept to
>> metadata. Tools that understand it would see that data and
>> be able to act on it, tools that don't understand it would simply
>> write it to the METADATA file incase in the future a tool that
>> does understand it needs to act on it.
>>
>> Essentially first class support for extending the metadata outside
>> of a PEP process means that outside of the stdlib people can
>> experiment and try new things, existing tools will continue to work
>> and just ignore that extra data (but leave it intact), new tools will be
>> able to utilize it to do something useful. Ideally as a new concept is
>> tested externally and begins to gain acceptance a new metadata
>> version could be created that standardizes that field as part of the
>> spec instead of an extension.
>
> Agreed, and this is the kind of thing a v1.3 metadata PEP could
> define. It just needs to be properly namespaced, and the obvious
> namespacing mechanism is PyPI project names.
>
> Cheers,
> Nick.

Wheel deals with this somewhat by including a

Packager: bdist_wheel

line in WHEEL so that you can deal with packager-specific bugs.

Bento uses indentation so you can have sections:

Key: value
   Indented Key: value