On Oct 19, 2017, at 3:55 PM, Thomas Kluyver <thomas@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.