On Oct 19, 2017, at 3:15 PM, Thomas Kluyver firstname.lastname@example.org wrote:
On Thu, Oct 19, 2017, at 08:01 PM, Donald Stufft wrote:
On Oct 19, 2017, at 2:54 PM, Thomas Kluyver <email@example.com mailto:firstname.lastname@example.org> wrote:
I don't think this needs to be controversial. They are a de-facto packaging standard, whether or not that's theoretically necessary. There's more than one tool that can create them (setuptools, flit), and more than one that can consume them (pkg_resources, entrypoints). Lots of packages use them, and they're not going anywhere soon. Describing the format properly seems like a clear win.
I disagree they are a packaging standard and I think it would be crummy to define it as one. I believe it is a setuptools feature, that flit and entrypoints wants to integrate with a setuptools feature is fine, but that doesn’t make it a packaging standard just because it came from setuptools. I agree that describing the format properly is a clear win, but I believe it belongs in the setuptools documentation.
pip and distlib also independently read this format without going through setuptools. It's a de-facto standard already. Entry points are also the most common way for packages to install command-line scripts, and the most effective way to do so across different platforms. So it's essential that install tools do understand this.
It’s only essential in that we support a very limited subset specifically for console scripts, which long term we should be extracting from entry points and using something dedicated to that. Generating script wrappers is a packaging concern, and if this proposal was about documenting the console_scripts key in an entry_points.txt file to trigger a console script being generated, then that’s fine with me.
Much of our packaging standards were built out of setuptools features anyway - why pretend that this is different?
Because it is? A generic plugin mechanism is not a packaging feature any more then a HTTP client is a packaging feature, but setuptools contains one of those too. Since setuptools was in large part a packaging library, it will of course contain many packaging features that we’re going to standardize on, but something being in setuptools does not in fact make it a packaging feature in and of itself.
As an example of another setuptools feature that isn’t a packaging feature, I also would be against adding the resource APIs in a packaging standard because they’re not a packaging feature either, they’re a python import module feature (which is why Brett Cannon and Barry are adding them to importlib instead of trying to make a packaging PEP for them).