On Wed, 18 Oct 2017 at 17:54 Nick Coghlan <ncogh...@gmail.com> wrote:
> On 19 October 2017 at 04:18, Alex Grönholm <alex.gronh...@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.
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
