> On Oct 20, 2017, at 7:57 AM, Thomas Kluyver <tho...@kluyver.me.uk> wrote: > > On Fri, Oct 20, 2017, at 12:50 PM, Donald Stufft wrote: >> * Since it is a packaging standard, then it is expected that all >> packaging tools will be updated to work with it. > > Where packaging tools need to know about it, they already have to. > Where they don't, writing a standard doesn't imply that every tool has > to implement it. Documenting it doesn't change either case, it just > makes life easier for tools that do need to use it.
Packaging tools shouldn’t be expected to know anything about it other than the console_scripts feature (which shouldn’t exist as an entry point, but currently does for historical reasons). Publishing tools should have a way for additional files that the publishing tool wasn’t even aware might exist someday to get added to the metadata directory, installation tools should preserve those files when installing them. With those two generic features, then entry points (and other things!) can be written on top of the ecosystem *without* needing to standardize on one solution for one particular non-packaging problem. If a publishing tool doesn’t want to provide that mechanism, then that is fine, but that limits their audience (in the same way that not building C extensions limits their audience, people who need that capability won’t be able to use them). > >> * We’re explicitly saying that this is the one true way of solving this >> problem in the Python ecosystem. > > I don't buy that at all. We're saying that it exists, and this is what > it is. It’s literally the way all of our packaging standards are written. Don’t use eggs, wheels are the one true way, don’t use YOLO versions, PEP 440 is the one true way, don’t add arbitrary extensions to the simple repo format, PEP 503 API Is the one true way, etc etc etc. > >> * We stifle innovation (hell just including it in setutools at all does >> this, but we can’t unopen that can of worms). > > I don't think that's true to any significant extent. Having a standard > does not stop people coming up with something better. It doesn’t actively prevent someone from coming up with something better no, but what it does do is add a pretty huge barrier to entry for someone who wanted to come up with something better. It’s the same way that something being added to the stdlib stifles competition. When something is “the standard”, it discourages people from even trying to make something better— or if they do make other people from trying it, unless “the standard” is really bad. > >> * 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). > > It hasn't changed in years, as far as I know, and it's so widely used > that any change is likely to break a load of stuff anyway. As we've > already discussed for caching, we can improve by building *on top* of it > relatively easily. And ultimately I think that bringing it out into > daylight leads to a healthier future than leaving it under the stone > marked 'setuptools''. > If I could guess, I’d say it hasn’t changed in years because setuptools has had bigger things to work on and not enough time to do it in. _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
