> On Oct 20, 2017, at 7:31 AM, Thomas Kluyver <tho...@kluyver.me.uk> wrote: > > On Fri, Oct 20, 2017, at 12:15 PM, Donald Stufft wrote: >> Tell you what, I’ll drop everything today and write up a PEP... > > Donald, why are you so determined that this spec should not be created? Your > time is enormously valuable, so why would you drop everything to write a PEP > which implies changes to tooling, simply so that we don't document the status > quo? Even if we do make that change, there are thousands of existing packages > using the existing de-facto standard, so it would still be valuable to > document it. > > If it makes things easier, I'll host the spec on my own site and add a 'see > also' from the specs page of the packaging user guide (because I think people > would expect it to be there, even if it's not the 'right' place). But I don't > think anyone else has expressed any objection to putting the spec there. > > Thomas
I mean, it’s a PEP I was already planning on writing at some point, because I’ve *never* liked the fact that our console script support was reliant on a setuptools feature so all I’d be doing is re-prioritizing work I was already planning on doing. I’m also completely happy with documenting the status quo, which from a packaging stand point means documenting console_scripts— it doesn’t mean pulling in an entire setuptools feature. I’m not even against documenting the entire feature, *if* it’s done inside of setuptools where it belongs. What I am against, is moving the entire entry points feature from a setuptools feature to a packaging standard. It is at best, tangental to packaging since outside of console_scripts it’s only real relation is that it uses features of the packaging ecosystem and happened to come from setuptools (but it could have just as easily been written externally to setuptools). Making it a packaging standard comes with several implications: * Since it is a packaging standard, then it is expected that all packaging tools will be updated to work with it. * We’re explicitly saying that this is the one true way of solving this problem in the Python ecosystem. * We stifle innovation (hell just including it in setutools at all does this, but we can’t unopen that can of worms). * We make it actively harder to improve the feature (since once it’s part of the purview of packaging standards, all of distutils-sig gets to weigh in on improvements). I don’t get why anyone would want to saddle all of the extra implications and work that comes with being a packaging standard on a feature that isn’t one and doesn’t need to be one. We are at our best when our efforts are on generalized mechanisms that allow features such as entry points to be implemented on top of us, rather than trying to pull in every tangential feature under the sun into our domain. _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
