On Wed, 18 Oct 2017 at 17:54 Nick Coghlan <ncoghlan@gmail.com> wrote:
On 19 October 2017 at 04:18, Alex Grönholm <alex.gronholm@nextday.fi> wrote:
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?

The idea has been raised, but we've been hesitant for the same reason we're inclined to take distutils out: packaging APIs need to be free to evolve in line with packaging interoperability standards, rather than with the Python language definition.

Barry Warsaw & Brett Cannon recently mentioned something to me about working on a potential runtime alternative to pkg_resources that could be installed without also installing setuptools, but I don't know any of the specifics (and I'm not sure either of them follows distutils-sig).

I've been following distutils-sig for a couple of years now. :)

And what Barry and I are working on is only a subset of pkg_resources, specifically the reading of data files included in a package. We aren't touching any other aspect of pkg_resources.

Heck, until this discussion, "entry points" == "console scripts" for me so I don't really know what y'all are talking about standardizing when it comes to plug-in systems and metadata. Having said that, I do understand why Donald doesn't want to just go ahead and standardize something by giving it the level of a spec on packaging.python.org just because it's out there. But since entry points seem to be used widely enough, having them written down appropriately also seems reasonable.

As a compromise, could entry points be documented as Thomas is suggesting, but have a note at the top saying something along the lines of "entry points are considered a setuptools-specific feature, but their wide spread use warrants a clear understanding of how they function for other packaging tools choose on their own to also support them"? Basically acknowledge there are ad-hoc, folk standards in the community that a decent chunk of people rely on and thus docs would be helpful, but don't need to be promoted to full-on, everyone-implements standard.