I don’t think changing the name would solve anything and I think the process of doing so would be a large enough amount of effort that it’s not worth doing it. For similar reasons as to why even though I wanted to rename PyPI years ago, we ultimately decided not to.
It’s a complex topic I think. We’re not an authority in that you don’t have to listen to us if you don’t want to. We go out of our way to try and make our standards open so that anyone can come in and reimplement them and we try to make the various standards not depend too much on each other so for example, an sdist can end up producing something other than a wheel if it’s desired.
However, we’re also the group of people developing tools that have a huge amount of network effect behind them. For a lot of people if it’s not uploaded to PyPI and isn’t installable via pip, it simply doesn’t exist. These network effects existed long before PEP 453 or any sort of recognition from CPython / python-dev, and in general PEP 453 and the recognition from python-dev was not python-dev “picking a winner”, but rather them recognizing what was already the state of the ecosystem (although those same network effects that lead to those choices then end up boosted from that).
In that vein, what the PyPA members and the projects under that umbrella say does carry weight and always will regardless of what we call ourselves unless some new project/team comes along and gains enough mindshare and traction to the point that the general population no longer cares about the PyPA projects or keeping support with them.
Honestly, I think the true thrust of the issue is that the PyPA toolchain doesn’t support a particular use case very well and people with that use case have made and/or found a toolchain that does support it. I think that’s great and I’m glad they’ve found that. However, they then feel forced to support a toolchain that doesn’t well support it because a large number of their users want to use that toolchain anyways and they’re looking for a magic bullet that they hope will make people no longer care about the PyPA tooling so they don’t feel bad about wanting to not support it.
Unfortunately for them, I don’t think there is a magic bullet and I don’t think changing the name is going to have ~any impact. I think the only things that can have impact to solve the underlying issue of “the PyPA toolchain doesn’t support my use case and I wish it did or I wish it would go away” is:
- Convince a group of people who are largely volunteers to spend their free time supporting your use case.
- So far this hasn’t been working for one reason or another, mostly because all of the people working on these projects are already over extended and don’t have the bandwidth to tackle a use case that they don’t personally have.
- Provide engineering resources to help make that use case better supported (this can be either volunteering themselves, providing money to make it possible to run a RFP and get someone to do funded work on the project, or getting a company to donate (an) engineer(s)).
- Advocate for your preferred tooling and potentially stop supporting the PyPA tooling yourself altogether and see if you can overcome the network effects that the PyPA tooling has.
Given all of that, I am -0.5 on changing the A in PyPA to something else, since I think it has cost and will be mostly pointless, but if the rest of the PyPA wanted to do it I wouldn’t block it. I am -1 on changing the name to some entirely new acronym or whatever because I think that is just far too much effort and introduces far too much confusion for any benefit to be realized.