On Tue, Aug 28, 2012 at 10:07 PM, Donald Stufft <donald.stu...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
