http://setuptools.readthedocs.io/en/latest/formats.html?highlight=entry_points.txt#entry-points-txt-entry-point-plugin-metadata
http://setuptools.readthedocs.io/en/latest/pkg_resources.html?highlight=pkg_resources#creating-and-parsing It is not very complicated. It looks like the characters are mostly 'python identifier' rules with a little bit of 'package name' rules. I am also concerned about the amount of parsing on startup. A hard problem for certain, since no one likes outdated cache problems either. It is also unpleasant to have too much code with a runtime dependency on 'packaging'. On Wed, Oct 18, 2017 at 1:00 PM Paul Moore <p.f.mo...@gmail.com> wrote: > On 18 October 2017 at 17:48, Doug Hellmann <d...@doughellmann.com> wrote: > > Excerpts from Thomas Kluyver's message of 2017-10-18 15:52:00 +0100: > >> We're increasingly using entry points in Jupyter to help integrate > >> third-party components. This brings up a couple of things that I'd like > >> to do: > >> > >> 1. Specification > >> > >> As far as I know, there's no document describing the details of entry > >> points; it's a de-facto standard established by setuptools. It seems to > >> work quite well, but it's worth writing down what is unofficially > >> standardised. I would like to see a document on > >> https://packaging.python.org/specifications/ saying: > >> > >> - Where build tools should put entry points in wheels > >> - Where entry points live in installed distributions > >> - The file format (including allowed characters, case sensitivity...) > >> > >> I guess I'm volunteering to write this, although if someone else wants > >> to, don't let me stop you. ;-) > >> > >> I'd also be happy to hear that I'm wrong, that this specification > >> already exists somewhere. If it does, can we add a link from > >> https://packaging.python.org/specifications/ ? > > > > 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). > Also, it's not clear how a tool like flit might implement entry points > - again, because the specifications don't describe how the metadata is > stored. > > +1 from me on moving the entry point specification to > https://packaging.python.org/specifications/ > > Paul > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > https://mail.python.org/mailman/listinfo/distutils-sig >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
