[Distutils] Entry points: specifying and caching

[Donald Stufft]

> On Oct 20, 2017, at 8:06 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
> On 20 October 2017 at 21:15, Donald Stufft <donald at stufft.io <mailto:donald at stufft.io>> wrote:
> Tell you what, I’ll drop everything today and write up a PEP that adds metadata for console scripts to the packaging metadata where it belongs,
> 
> Donald, you're making the same mistake I did with PEP 426: interoperability specifications are useless without a commitment from tooling developers to actually provide implementations that know how to read and write them. And since any new format you come up with won't be supported by existing pip and pkg_resources installations, there won't be any incentive for publishers to start using it, which means there's no incentives for runtime libraries to learn how to read it, etc, etc.

Not particularly no.

I can promise you 100% that pip will support it in the next version once I write it. I can also promise you that setuptools will have a PR to support it (not pkg_resources, because console scripts are a install time feature not a runtime feature), and I assume Jason would be happy to merge it.

So there’s commitment from at least one tool.

The “existing installations” is horse shit, because existing implementations won’t support *any* new feature of anything so it can literally be used as a justification for doing nothing about anything except standardizing what already exists. I guess we shouldn’t have done PEP 517 or PEP 518 because, by your logic here, since it won’t be supported by existing tooling, there won’t be any incentive for people to use it ever.

> 
> In this case, we already have a perfectly serviceable format (entry_points.txt), a reference publisher (setuptools.setup) and a reference consumer (pkg_resources). The fact that the reference consumer is pkg_resources rather than pip doesn't suddenly take this outside the domain of responsibility of distutils-sig as a whole - it only takes it outside the domain of responsibility of PyPI.
> 
> So if you want to say it is neither pip's nor PyPI's responsibility to say anything one way or the other about the entry points format (beyond whether or not they're used to declare console scripts in a way that pip understands), then I agree with you entirely. This spec isn't something you personally need to worry about, since it doesn't impact any of the tools you work on (aside from giving pip's existing console_scripts implementation a firmer foundation from an interoperability perpsective).

My objection has absolutely nothing to do with whether pip is the consumer or not. My objection is entirely based on the fact that a plugin system is no .a packaging related feature and it doesn’t become one because a packaging tool once added a plugin system.

> 
> So the core of our disagreement is whether or not interfaces involving pip and PyPI represent the limits of distutil-sig's responsibility. They don't, and that's reflected in the fact we have a split standing delegation from Guido (one initially to Richard Jones and later to you for changes that affect PyPI, and one to me for packaging ecosystem interoperability specifications in general)

No that’s not the core of our disagreement. The core of our disagreement is whether random runtime features suddenly become a packaging concern because they were implemented by one packaging tool once.

>  
> so we can move console_scripts entry point to a legacy footnote as far as packaging systems go. Then we can discuss whether an arbitrary plugin system is actually a packaging related spec (it’s not) on it’s own merits.
> 
> Instructing publishing system developers on how to publish pkg_resources compatible entry points is indeed a Python packaging ecosystem level concern. 

No it’s really not.

> 
> Whether that capability survives into a hypothetical future metadata specification (whether that's PEP 426+459 or something else entirely) would then be a different question, but it isn't one we need to worry about right now (since it purely affects internal interoperability file formats that only automated scripts and folks maintaining those scripts need to care about, and we'd expect entry_points.txt and PKG-INFO to coexist alongside any new format for a *long* time).
> 
> Cheers,
> Nick.
> 
> -- 
> Nick Coghlan   |   ncoghlan at gmail.com <mailto:ncoghlan at gmail.com>   |   Brisbane, Australia

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20171020/0ec8faa6/attachment-0001.html>