<p dir="ltr"><br>
On 1 Jan 2014 20:58, "Paul Moore" <<a href="mailto:p.f.moore@gmail.com">p.f.moore@gmail.com</a>> wrote:<br>
><br>
> On 31 December 2013 22:53, Marcus Smith <<a href="mailto:qwcode@gmail.com">qwcode@gmail.com</a>> wrote:<br>
> > for #1, during installation, I imagine the new setuptools would build the<br>
> > sdist (and any entry_point declarations) using 2.0 metadata.<br>
><br>
> So assuming the package consuming the entry point converts to using<br>
> metadata 2.0 APIs (and does *not* try to have a compatibility mode<br>
> that falls back to the old setuptools format) users would be required<br>
> to use an up to date setuptools (installation with older setuptools<br>
> would be unsupported). Also they would need to reinstall SomeExtension<br>
> for it to be recognised by the new consumer.<br>
><br>
> > for #2, the pip installer would be responsible for converting<br>
> > "entry_points.txt" during the install (or maybe just forcing a "bdist_wheel"<br>
> > rebuild when it detects metadata < 2.0)<br>
><br>
> Again requiring users to be running a suitably recent pip and/or<br>
> setuptools and reinstall SomeExtension.<br>
><br>
> Presumably the new setuptools and pip would have to maintain both the<br>
> Metadata 2.0 format data and the old-style entry_points.txt format for<br>
> a period of compatibility. We should probably define the length of<br>
> that transition period as part of the plan for Metadata 2.0 going<br>
> live.<br>
><br>
> So there is some user impact, but it sounds like it's manageable. Cool.</p>
<p dir="ltr">Yeah, one of the big benefits of switching to the JSON format with a different filename was letting us distribute both the old and new metadata formats in parallel.</p>
<p dir="ltr">The aim is to allow newer versions of pip and setuptools to be faster and more reliable, without breaking older versions.</p>
<p dir="ltr">Cheers,<br>
Nick.</p>
<p dir="ltr">><br>
> Paul<br>
</p>