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_poin...
http://setuptools.readthedocs.io/en/latest/pkg_resources.html?highlight=pkg_...
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.