[Python-Dev] Edits to Metadata 1.2 to add extras (optional dependencies)
Nick Coghlan
ncoghlan at gmail.com
Tue Aug 28 14:28:57 CEST 2012
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.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Python-Dev
mailing list