[Distutils] Entry points: specifying and caching

[Donald Stufft]

> On Oct 19, 2017, at 4:36 PM, Thomas Kluyver <thomas at kluyver.me.uk> wrote:
> 
> On Thu, Oct 19, 2017, at 09:04 PM, Donald Stufft wrote:
>> 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 don't see any advantage in describing the file format but then
> pretending that there's only section in it. We're not prescribing any
> particular meaning or use for other sections, but it seems bizarre to
> not describe the possibilities. console_scripts is just one use case.

Because the feature is unrelated to packaging other than the fact we currently utilize it for console_scripts. A spec to standardize console_scripts is a good thing, a spec to standardize an almost entirely unrelated feature for packaging is a bad thing. 

> 
> Also, entry points in general kind of are a packaging thing. You specify
> them in packaging metadata, both for setuptools and flit, and the
> packaging tools write entry_points.txt. It's not the only way to create
> a plugin system, but it's the way this one was created.

You can describe lots of things in the packaging metadata, because one of the features of the packaging metadata is you can add arbitrary files to the dist-info directory. Entrypoints are one such file that some projects add to that directory, but there are other examples and jsut becuause it involves adding files to that, does not mean it belongs to “packaging”.

> 
> I honestly don't get the resistance to documenting this as a whole. I'm
> not proposing something that will add a new maintenance burden; it's a
> description of something that's already there. Can't we save the energy
> for discussing a real change or new thing?
> 

I don’t get the resistance to documenting this where it belongs. Its not any more difficult to document things in the setuptools repository than it is to document it in the packaging specs repository.