[Distutils] Entry points: specifying and caching

[Nick Coghlan]

On 20 October 2017 at 21:15, Donald Stufft <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.

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).

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)


> 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.

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   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20171020/df46e972/attachment-0001.html>