On Wed, Oct 18, 2017 at 2:57 PM Paul Moore <p.f.moore@gmail.com> wrote:
On 18 October 2017 at 19:42, Thomas Kluyver <thomas@kluyver.me.uk> wrote:
> On Wed, Oct 18, 2017, at 05:59 PM, Paul Moore wrote:
>> > I've always used the setuptools documentation as a reference. Are you
>> > suggesting moving that information to a different location to
>> > allow/encourage other tools to implement it as a standard?
>> I've never used entry points myself (other than the console script
>> entry points supported by packaging) but a quick Google search found
>> http://setuptools.readthedocs.io/en/latest/setuptools.html#dynamic-discovery-of-services-and-plugins
>> as the only obvious candidate for documentation (and a bit later I
>> thought of looking under pkg_resources and found
>> http://setuptools.readthedocs.io/en/latest/pkg_resources.html#entry-points).
>> This doesn't really say how the entry point data is stored in the
>> project metadata, so it's not clear how I'd read that data in my own
>> code (the answer is of course to use pkg_resources, but the point of
>> documenting it as a standard is to allow alternative implementations).
> I have in fact made an alternative implementation (PyPI package
> entrypoints) by 'reverse engineering' the format. A simple text-based
> format doesn't really justify the term 'reverse engineering', but for
> instance it wasn't obvious to me that the names were case sensitive,
> whereas Python's standard config parser treats keys as case-insensitive.
> Daniel:
>> http://setuptools.readthedocs.io/en/latest/formats.html?highlight=entry_points.txt#entry-points-txt-entry-point-plugin-metadata
> Thanks, this link is closer than any I found to a specification. There
> are docs on how to create entry points in setup.py and how to use them
> with pkg_resources, but that's the only bit I've seen that describes the
> interchange file format.

Agreed, I hadn't found that, either.

> I think we can probably expand on it a bit, though! I'll try to put
> together something for packaging.python.org.

One thing that immediately strikes me is that the encoding of the file
is unspecified...

Now that's an easy one to clear up, since there is only one worthwhile encoding.