let's consider 2 cases

1) someone publishes an sdist extension, SomeExtension-1.0.tar.gz up on pypi, that uses the setuptools "entry_points" keyword

2) someone publishes a wheel extension, SomeExtension-1.0.whl that has a traditional "entry_points.txt" file baked into it.

and then PEP426 goes live, and pip/setuptools refactor themselves to be compliant, i.e. setuptools starts generating 2.0 metadata, and pip (via a new pkg_resources, distlib, or some other alternative) is able to process 2.0 metadata.

for #1, during installation, I imagine the new setuptools would build the sdist (and any entry_point declarations) using 2.0 metadata.

for #2, the pip installer would be responsible for converting "entry_points.txt" during the install (or maybe just forcing a "bdist_wheel" rebuild when it detects metadata < 2.0)

On Tue, Dec 31, 2013 at 1:35 PM, Marcus Smith <qwcode@gmail.com> wrote:

> Tools should just do automatic conversion of entry_points.txt to the
> new metadata format when .dist-info is in use.

Yep, as with other fields, my aim is to create a format that can be derived from the existing setuptools metadata. That way, PyPI can publish it even for projects that only upload metadata using the current setuptools formats.

ok, but to be clear about the *usage* of the "entry_points" setup keyword...
that's the user question. Should someone feel ok with adopting this now?
It sounds like you're saying yes.

setuptools users should assume either:
a) new-style tool consumers of metadata will auto-convert old-style entry points
b) setuptools will update the implementation of "entry_points" to produce be PEP459 compliant