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.