Daniel Holth kirjoitti 18.10.2017 klo 21:06:
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'.
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.mo...@gmail.com
<mailto:p.f.mo...@gmail.com>> wrote:
On 18 October 2017 at 17:48, Doug Hellmann <d...@doughellmann.com
<mailto: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
<mailto: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
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
