On 20 October 2017 at 22:18, Donald Stufft <donald@stufft.io> wrote:

The “existing installations” is horse shit, because existing implementations won’t support *any* new feature of anything so it can literally be used as a justification for doing nothing about anything except standardizing what already exists. I guess we shouldn’t have done PEP 517 or PEP 518 because, by your logic here, since it won’t be supported by existing tooling, there won’t be any incentive for people to use it ever.

No, because PEP 517 and 518 actually change the UX for *publishers* away from setup.py to pyproject.toml + whatever build system they choose, while allowing the definition of a *common* setup.py shim for compatibility with older clients.

By contrast, it's relatively rare for people to edit entry_points.txt by hand - it's typically a generated file, just like PKG-INFO.

For any *new* console_scripts replacement, you're also going to have define how to translate it back to entry_points.txt for compatibility with older pip installations, and that means you're also going to have to define how to do that without conflicting with any other pkg_resources entry points already declared by a package.

Those two characteristics mean that entry_points.txt has a lot more in common with PKG-INFO than it does with setup.py, and that similarity is further enhanced by the fact that it's a pretty easy format to document.

So if you want to say it is neither pip's nor PyPI's responsibility to say anything one way or the other about the entry points format (beyond whether or not they're used to declare console scripts in a way that pip understands), then I agree with you entirely. This spec isn't something you personally need to worry about, since it doesn't impact any of the tools you work on (aside from giving pip's existing console_scripts implementation a firmer foundation from an interoperability perpsective).

My objection has absolutely nothing to do with whether pip is the consumer or not. My objection is entirely based on the fact that a plugin system is no .a packaging related feature and it doesn’t become one because a packaging tool once added a plugin system.

You're acting like you believe you have veto power over this topic. You don't - it's not a PyPI related concern, and it doesn't require any changes to pip or warehouse.

I'd certainly be *happier* if you were only -0 rather than -1, but your disapproval won't prevent me from accepting Thomas's PR either way.

Cheers,

Nick.

Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia