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

[Nick Coghlan]

On Tue, Aug 28, 2012 at 11:23 PM, Donald Stufft <donald.stufft at gmail.com> wrote:
> To be more specific, there is setup.cfg (which I dislike for other reasons),
> and
> then there is METADATA. setup.cfg is an ini file but METADATA is a simple
> key: value file with a flat namespace so any namespacing you want to do in
> METADATA needs to be done at the key level.

We're talking about the format for v1.3 of the metadata. That format
is not defined yet, so it's not obligatory for it to remain a flat key
value store. However, there are advantages to keeping it as such, so
I'm fine with Daniel's suggested approach.

The only thing I really care about is the namespacing, for the same
reasons the IETF wrote RFC 6648, as Petri linked earlier [1].
Establishing proper name registration rules can categorically
eliminate a bunch of problems further down the line (such as the past
confusion between which metadata entries were defined by PEPs and
which were setuptools-specific extensions that other tools might not
understand).

With PyPI based namespacing we get clear orthogonal naming with clear
lines of authority:

1. PEPs continue to define the core metadata used by PyPI, the
standard library (once we get updated packaging support in place) and
most other tools
2. Any members of the community with a specific interest can register
a PyPI project to define additional metadata without risking naming
conflicts. This need may arise in the context of a specific project,
and thus use that project's name, or else it may be a project
registered for the express purpose of being a metadata namespace, and
not actually correspond to any installable module. The main point is
to take advantage of an existing automated Python-specific name and
resource registry to avoid naming conflicts without Java-style reverse
DNS based clutter, and without python-dev having to explicitly approve
each and every metadata extension.

Cheers,
Nick.

[1] https://tools.ietf.org/html/rfc6648#section-4

Cheers,
Nick.

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