The PyPA calling itself an “Authority” produces a lot of problems. Apparently the name was intended initially as a joke, but nobody outside a select few knows about that. People tend to think that everything the PyP"A" says about Python packaging is gospel.
This produces a lot of friction because the tools and standards developed by the PyP"A" are generally limited and can’t handle some use cases correctly, however users often insist that they want “pip wheels” because it’s the “official” way as christened by the “Authority”. Several packagers maintainers have been unreasonably strained by this situation (producing functional packages under a dysfunctional spec) and would like the “Authority” to be dropped.
The Python Cryptographic Authority aspires to be the primary resource for Python developers needing cryptographic libraries, but our authority is derived solely from developer opinion of the quality of our software.
…
PyCA is just some people hanging out, making computer programs. We’re not “official”, for any definition thereof.
I agree, I don’t like the joke either. It was more of a “please listen to us” at first. I’ve never felt like a member of that group or been clear on who is exactly. There’s lots of other “A” words.
2¢: As someone moderately new to Python (picked up 3.5 in 2014), I definitely took the “A” quite seriously. I immediately assumed that anything issuing from the PyPA … opinion, code, whatever … held an appreciable measure of official weight.
If it’s more supposed to be, “we are a group of people ((closely?) associated with core Python development?) that are working on packaging tools, but please don’t take anything we say/create as being blessed as ‘the one true Python way,’” then I’d say the name fosters a (likely problematic) mistaken impression.
I suspect one likely practical consequence of the current name is an inhibition of “self-perceived non-insiders” offering contributions to PyPA-branded projects. If there is no such thing as an ‘insider,’ then IMO a different name for the “organization” would be a really good idea.
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.
No, I’m saying that changing the PyPA name isn’t going to improve the situation and is just as likely to make the overall situation worse by introducing extra confusion and by expending effort that could be better spent improving the tooling itself.
As far as promoting conda more broadly-- I don’t use conda, I’ve never used conda, I have no interest in personally using conda. It solves zero problems I have and introduces more problems that the PyPA tooling has already solved for my workflows. I do not plan on spending any of my time evangelizing a tool that I do not personally have any interest in using.
The conda advocates have been told multiple times that if they want to improve the documentation for packaging.python.org or some other place with regards to how it displays conda, then they’re more than welcome to submit PRs for review to try and figure out a better path forward there. There’s been an open issue on packaging.python.org for years tagged as help wanted (pypa/packaging.python.org#367) waiting for someone to contribute to it. If you care about advocating for these tools and you want it to happen, then you need to contribute. It’s not going to happen because you sit in GitHub or discourse and whine about how unfairly you’re being treated and demand free labor that you’re not even willing to give yourself.
It would be helpful to have clearer rules for membership in PyPA. For me it has always been something to feel an outsider to, although I’ve written some things, but not so many things lately.
I see we have split the discussion. Some people complain when they are offered a non-PyPA tool. Other people feel uncomfortable contributing to PyPA projects because they are not authoritarians* themselves.
No-one is entitled to demand that anyone else spend their personal time in any particular way. And someone stating explicitly that their personal priorities don’t include a particular issue, shouldn’t be criticised for making that statement.
Better would be to try to work out how to get people who are motivated to evangelise conda involved. A start would be finding someone interested and pointing them at pypa/packaging.python.org#367. That’s probably about as authoritative place to promote conda as you could hope for.
Well I did propose that the PyPA rename themselves to something that doesn’t imply it has a special blessed status. Other people have expressed confusion with the name as well. So why is that proposal dismissed?
I think I went into some great detail to explain why I believe that changing the name isn’t going to do much to solve the underlying problem, and what little effect it has will be outweighed by the cost of changing the name.
I also made it pretty clear that if other PyPA members wanted to change the “A” in PyPA to something else, I wasn’t going to block it.
I’ve done pretty much nothing to “dismiss” the proposal other than express my own opinion while still allowing space for the rest of the PyPA to disagree with me. As far as I am aware I’m still allowed to have my own opinions on proposals and what their likely efficacy will be.
Just noting here since I think it’s worth reiterating – for (at least one of) the motivating pain point(s) for this thread, there’s an open offer for someone to get paid to work to fix it.
IMO Let’s not jump into a vote prematurely. We should let this discussion settle down for a bit before going and deciding what to do, so that folks can chime in with their thoughts in the discussion.
Right now, to be reductive, the argument for a name change is: the tooling built by PyPA isn’t covering 100% of the use cases which causes (some?) user confusion, so don’t call it “authority”.
I don’t see how any tool can cover 100% of the use cases. I would like to see someone directly address why they think a name change will be more impactful than actually working to improve the tooling / documentation under the “PyPA” name.
That said, I’m not intending to block such a vote from happening ever – it’s just feels too early to go to a vote to me right now.
And… If no PyPA member is going to state that they are in favor of this change, I don’t think there’s much reason to go through the effort of conducting a vote anyway.
Changing the “PyPA” name is a documentation change, in some way. As for the tooling, that’s easier said than done. If people went through the hassle of creating conda and its ecosystem (which represents a lot of work), it’s because they determined that pip couldn’t work for their needs.
