[Distutils] Entry points: specifying and caching
donald at stufft.io
Thu Oct 19 15:29:32 EDT 2017
> On Oct 19, 2017, at 3:15 PM, Thomas Kluyver <thomas at 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 <thomas at kluyver.me.uk <mailto:thomas at 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).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Distutils-SIG