Daniel Holth kirjoitti 18.10.2017 klo 21:06:


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'.
Wasn't someone working on implementing pkg_resources in the standard library at some point?

On Wed, Oct 18, 2017 at 1:00 PM Paul Moore <p.f.moore@gmail.com> wrote:
On 18 October 2017 at 17:48, Doug Hellmann <doug@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
as the only obvious candidate for documentation (and a bit later I
thought of looking under pkg_resources and found
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

+1 from me on moving the entry point specification to

Distutils-SIG maillist  -  Distutils-SIG@python.org

Distutils-SIG maillist  -  Distutils-SIG@python.org