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 <qwc...@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 >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
