> On Oct 20, 2017, at 1:32 AM, Nick Coghlan <ncogh...@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.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?
I’m *not* saying that flit doesn’t nee to know how to generate entry points if
a entry points using project wants to use flit, but what I am saying is that
entry points isn’t a packaging specification. It’s a setuptools feature that
should live within setuptools.
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
