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

[Donald Stufft]

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 <dholth at gmail.com (mailto:dholth at 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 | ncoghlan at gmail.com (mailto:ncoghlan at gmail.com) | Brisbane, Australia
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org (mailto:Python-Dev at python.org)
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/donald.stufft%40gmail.com
> 
> 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20120828/0fd13595/attachment.html>