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.
I think any spec which doesn't include first class support for extending it with new metadata is going to essentially kick the can down the road and solve the problems of today without leaving room to solve the problems of tomorrow. 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. On Tuesday, August 28, 2012 at 7:45 AM, Nick Coghlan wrote: > On Tue, Aug 28, 2012 at 9:04 PM, Daniel Holth <dho...@gmail.com > (mailto:dho...@gmail.com)> wrote: > > Setuptools just uses path.exists() when it needs a particular file and will > > not bother parsing pkg-info at all if it can help it. The metadata edits > > for 1.2 fold some of those files into metadata. > > > You can't use path.exists() on metadata published by a webservice (or > still inside a zipfile), but you can download or read the main > metadata file. > > Still, I don't really care whether or not such a field indicating the > presence of custom metadata is added, I'm mainly registering a strong > -1 on allowing extension fields (in the form of X- headers or CSS > style prefixed headers) in the metadata file itself. > > Cheers, > Nick. > > -- > Nick Coghlan | ncogh...@gmail.com (mailto:ncogh...@gmail.com) | Brisbane, > Australia > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org (mailto:Python-Dev@python.org) > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/donald.stufft%40gmail.com > >
_______________________________________________ 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