> On Oct 19, 2017, at 3:55 PM, Thomas Kluyver <tho...@kluyver.me.uk> wrote: > > On Thu, Oct 19, 2017, at 08:29 PM, Donald Stufft wrote: >> Because it is? A generic plugin mechanism is not a packaging feature any >> more then a HTTP client is a packaging feature, but setuptools contains one >> of those too. Since setuptools was in large part a packaging library, it >> will of course contain many packaging features that we’re going to >> standardize on, but something being in setuptools does not in fact make it a >> packaging feature in and of itself. > > My argument is not that it's in setuptools, it's that > > 1. It's already processed by multiple packaging tools > 2. Any tool producing wheels which include command line tools basically has > to use entry points (or include a bunch of redundant complexity to make > command-line wrappers). It's a de-facto part of the wheel spec, at least > until a replacement is devised - and since it works, replacing for semantic > cleanliness is not a priority. > > You're quite right that a plugin system doesn't need to be a packaging > standard. But that ship has sailed. It's already a standard format for > packaging, the only question is whether it's documented. Practicality beats > purity.
Like I said, I’m perfectly fine documenting that if you add an entry_points.txt to the .dist-info directory, that is an INI file that contains a section named “console_scripts” and define what is valid inside of the console_scripts section that it will generate script wrappers, then fine. But we should leave any other section in this entry_points.txt file as undefined in packaging terms, and point people towards setuptools for more information about it if they want to know anything more than what we need for packaging. I am against fully speccing out or adding more features to entry points as part of a packaging standardization effort. _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
