[Distutils] Entry points: specifying and caching

[Nick Coghlan]

On 20 October 2017 at 20:48, Donald Stufft <donald at stufft.io> wrote:

>
> On Oct 20, 2017, at 1:32 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>
> If we want to enable pytest plugin authors to use other build systems like
> flit, then those build systems need a defined interoperability format
> that's compatible with what pytest is expecting to see (i.e. entry point
> definitions that pkg_resources knows how to read).
>
>
> This is thinking about it wrong IMO.
>
> We could just as easily say if we want tools like flit to be able to
> package Twisted plugins then those build systems need a defined
> interoperability format that is compatible with what Twisted and that
> ecosystem is expecting.
>

Twisted already defines plugin discovery in an inherently
packaging-friendly way, since it's based on import names rather than
packaging metadata. Other plugin management systems like straight.plugins
are similar: they use Python's import system as their pub/sub channel to
advertise plugin availability, and accept the limitation that this means
all plugin APIs will be module level ones rather than being individual
classes or callables.


> The *ONLY* reason we should care at all about defining entry points as a
> packaging feature is console scripts, so we should limit our
> standardization to that. PBR has a runtime feature too where it inserts
> metadata into the .dist-info directory at build time and then a runtime API
> that reads that.. should we standardize that too?
>

No, because PBR isn't the defacto default build system that pip injects
into setup.py execution by default. That's the one point where the "de
facto standard" status of setuptools is relevant to the question of whether
the entry_points.txt format is a PyPA interoperability standard: it is,
because providing a functionally equivalent capability is required for
publishers to be able to transparently switch from setuptools to something
else without their end users noticing the difference.

Sure we *could* say "We don't want to standardise on that one, we want to
define a different one", but I think entry points are good enough for our
purposes, so inventing something different wouldn't be a good use of
anyone's time (see also: the perpetually deferred status of PEP 426).

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/afbb3376/attachment.html>