On Tue, Aug 28, 2012 at 8:28 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > 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.
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 _______________________________________________ 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
