As a second, I’ll second this sentiment. And I’ve raised packaging-like questions with the broader core developer group before - the responses tend to range between “what’s packaging” to “I don’t care about packaging” to “they can do whatever they want”. I’m afraid the most support from the core team comes from those of us who participate in this category, which is very few of us.
And there’s definite opposition to tools that change the “normal” way of launching Python. No tool that requires you to type anything besides python[3[.x]] has a chance of becoming the default in the upstream distributions, in part because of core dev preferences but also because the vast majority of users appear to want python[3] (rather than another tool or even py). The best way to get a new tool into the upstream distros is to prove that users are all installing that tool already.
And I’m saying “upstream distros” on purpose, because there’s no reason you couldn’t create a new distro that includes whatever default tool you like. In some ways, the core team would be happier to just release a source tag and let other groups do the builds and distribution.[1] The license explicitly allows this.
What we won’t ever accept is people trying to use our existing “reach” to promote their own tool. If your tool has the reach already, we’ll consider making users lives easier, but you aren’t going to become a popular tool by getting into upstream CPython first. Similarly, if pip started becoming something other than a way to install into the current Python environment, we’d probably be quite happy to drop it.
We’re not happy when users of other distros blame upstream for distro-invented problems… ↩︎