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 email@example.com wrote:
On 18 October 2017 at 17:48, Doug Hellmann firstname.lastname@example.org 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:
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... 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
+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