<div dir="ltr">On Mon, Feb 25, 2013 at 12:37 PM, Vinay Sajip <span dir="ltr"><<a href="mailto:vinay_sajip@yahoo.co.uk" target="_blank">vinay_sajip@yahoo.co.uk</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">




<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Daniel Holth <dholth <at> <a href="http://gmail.com" target="_blank">gmail.com</a>> writes:<br>

<br>
<br>
> I can accept a rename but there is no way to avoid having 2 names not 1 new<br>
> name for the feature.<br>
> We go halfway now. The next version can go any other way.<br>
<br>
</div>Just to be clear, the naming of "exports" vs. "entry points" was not the main<br>
thrust of my point - I mentioned it purely by way of explaining that part of the<br>
JSON snippet I posted.<br>
<br>
What I meant to say is that that parsing or writing a JSON file called<br>
entry_points.txt (or whatever) is just as easy as parsing or writing an<br>
ini-format file. However, the benefit of JSON is clear when composing a larger<br>
set of data from separate files (see the separate thread about metadata caching).<br>
<br>
One can more easily compose the data in entry_points.txt, METADATA,<br>
requires-dist.txt and anything else if they are just JSON files. That is what I<br>
do in my JSON metadata format - the dependency information is extracted from the<br>
metadata for a release into an aggregated form which is easier to use when doing<br>
dependency resolution.</blockquote><div><br></div><div style>We all must realize that incremental improvements are not harmful. Delay is harmful; there has been no obvious way to make a Python package this decade based on the idea that something better might be just around the corner or that the current way will be deprecated. </div>
<div style><br></div><div style>The goal of this version of the PEP is to better represent important setuptools metadata statically while imposing as near to zero cost as possible on the actual setuptools users. They will not welcome an unproven alternative that requires work on their part. Instead, we change things a little bit, support setuptools / distribute OR "something else" for 5 years, until "something else" is obviously, compellingly better.</div>
</div></div></div>