[Distutils] Entry points: specifying and caching

Daniel Holth dholth at gmail.com
Wed Oct 18 14:06:40 EDT 2017



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.moore at gmail.com> wrote:

> On 18 October 2017 at 17:48, Doug Hellmann <doug at 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 at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20171018/795729dd/attachment-0001.html>

More information about the Distutils-SIG mailing list