<div>
I personally think that at a minimum we should have X-Fields that</div><div>get moved into the normal METADATA file, and personally I would</div><div>prefer to just drop the X- prefix completely.
</div><div><br></div><div>I think any spec which doesn't include first class support for</div><div>extending it with new metadata is going to essentially kick</div><div>the can down the road and solve the problems of today without</div><div>leaving room to solve the problems of tomorrow.</div><div><br></div><div>I know that distutils2 have requires-dist, but for the sake of</div><div>argument pretend they don't. If there is first class support for</div><div>extending the metadata with new fields, a project could come</div><div>along, and add a requires-dist (or x-requires-dist) concept to</div><div>metadata. Tools that understand it would see that data and</div><div>be able to act on it, tools that don't understand it would simply</div><div>write it to the METADATA file incase in the future a tool that</div><div>does understand it needs to act on it.</div><div><br></div><div>Essentially first class support for extending the metadata outside</div><div>of a PEP process means that outside of the stdlib people can</div><div>experiment and try new things, existing tools will continue to work</div><div>and just ignore that extra data (but leave it intact), new tools will be</div><div>able to utilize it to do something useful. Ideally as a new concept is</div><div>tested externally and begins to gain acceptance a new metadata</div><div>version could be created that standardizes that field as part of the</div><div>spec instead of an extension.</div><div><br></div>
<div></div>
<p style="color: #A0A0A8;">On Tuesday, August 28, 2012 at 7:45 AM, Nick Coghlan wrote:</p>
<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
<span><div><div><div>On Tue, Aug 28, 2012 at 9:04 PM, Daniel Holth <<a href="mailto:dholth@gmail.com">dholth@gmail.com</a>> wrote:</div><blockquote type="cite"><div>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.</div></blockquote><div><br></div><div>You can't use path.exists() on metadata published by a webservice (or</div><div>still inside a zipfile), but you can download or read the main</div><div>metadata file.</div><div><br></div><div>Still, I don't really care whether or not such a field indicating the</div><div>presence of custom metadata is added, I'm mainly registering a strong</div><div>-1 on allowing extension fields (in the form of X- headers or CSS</div><div>style prefixed headers) in the metadata file itself.</div><div><br></div><div>Cheers,</div><div>Nick.</div><div><br></div><div>-- </div><div>Nick Coghlan | <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a> | Brisbane, Australia</div><div>_______________________________________________</div><div>Python-Dev mailing list</div><div><a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a></div><div><a href="http://mail.python.org/mailman/listinfo/python-dev">http://mail.python.org/mailman/listinfo/python-dev</a></div><div>Unsubscribe: <a href="http://mail.python.org/mailman/options/python-dev/donald.stufft%40gmail.com">http://mail.python.org/mailman/options/python-dev/donald.stufft%40gmail.com</a></div></div></div></span>
</blockquote>
<div>
<br>
</div>