On 20 October 2017 at 22:18, Donald Stufft <don...@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 | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
