> On Oct 19, 2017, at 3:15 PM, Thomas Kluyver <tho...@kluyver.me.uk> wrote: > > On Thu, Oct 19, 2017, at 08:01 PM, Donald Stufft wrote: >> >>> On Oct 19, 2017, at 2:54 PM, Thomas Kluyver <tho...@kluyver.me.uk >>> <mailto:tho...@kluyver.me.uk>> 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).
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
