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

On Oct 20, 2017, at 1:32 AM, Nick Coghlan <ncoghlan@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@gmail.com | Brisbane, Australia