Remove the "Authority" from Packaging

To be pedantic, I suppose I was referring to the Anaconda Repositories, accessible by default with the conda tool, that are maintained by Anaconda, Inc…
https://repo.continuum.io/

Conda Forge repositories must be manually enabled, or explicitly referenced after installing the Anaconda distribution, with:

conda config --add channels conda-forge

The main point I was trying to affirm is the importance that central aspects of a language ecosystem, such as packaging and distribution, be stewarded and by an official governing body (Authority) of representatives from across the community.

1 Like

This is somewhat orthogonal, but it’s one thing I really liked about the charter for the Steering Council: there is a limit as to how many SC members can work for the sane company, I presume to avoid the possibility for the same sort of subtle, unintentional influence on the language as what is described above for R.

Well, there’s no such official governing body, then. The PyP"A" doesn’t consist of representatives from accross the community. It’s just people who coopted one another, and it’s not even obvious how (i.e. I don’t think there are any formal rules as to how someone becomes a member of that body).

1 Like

The PSFmember.org donation page says, “Donation for the Packaging Workgroup” in its title. (PyPI.org > user profile drop-down > Donate)

Does that mean the “Authority” part of the name was dropped in the meantime, or is “Workgroup” just an old name forgotten in the attic?

The page title stroke me immediately today (after visiting PyPI to activate 2FA), so I came here to search for a possible reason. – Why did it strike me? Because I felt the “authority threat” that this discussion is seemingly talking about, too in the (not too far) past.

I feel it’s indeed hard to contribute. It’s a bit like if you didn’t interact with some of the maintainers personally (on conferences) you’ll have a hard time getting your PRs through. There is a strong (male white?) attitude ruling the GitHub issues & PRs landscape. Of course, that’s just a very personal observation, but it sure doesn’t come from pure fantasy.

Let me emphasize that I’m very attached to a positive image “Python” should convey. There should be a welcoming atmosphere in any Python community or workgroup. And yes, names convey an image and certainly can trigger behavioral change.

2 Likes

The PyPA and the Packaging-WG are two separate (but overlapping) groups. The working group is primarily concerned with funding and the disbursement of funds for packaging-related projects, see https://wiki.python.org/psf/PackagingWG for more details.

1 Like

Personally, I have not had this impression thus far from any part of the Python development community. While there have been a few times I’ve waited a bit long for feedback on PRs or had a few reviews that went unnoticed, the majority of the core devs are happy to help anyone with questions. This includes myself, and I’ve never interacted with any of the core developers in person.

If a PR goes unnoticed for a long period of time and the author reaches out through python-dev, it is usually reviewed. In the majority of cases I’ve seen, the author usually never reaches out (despite this being mentioned on the devguide).

Especially recently, the Python development community has become significantly more diversified. At least in more recent recent years, I’ve never seen anyone treated differently as a result of their ethnicity, skin color, gender, sexuality, etc. This may not be the case across every organization on GitHub, but it definitely has been for Python, at least from my experience.

The difficulties of contributing (from my interpretation) comes primarily from a lack of resources. There’s far more people submitting PRs on a day-to-day basis than there are active core developers and PR reviewers.

Hopefully this will improve in the near future once the Python triage team has a decent number of active members. Having a group dedicated towards PR review and categorization on GitHub will help to reduce the number of unaddressed PRs. This will also allow the core devs to spend less time on the preliminary steps, allowing them to potentially merge more PRs within the same amount of time.

6 Likes

I just took the PyPA at its word that they’re open to contributions. Result: I had a great experience getting started contributing to the PyPA docs. That’s why i’m here now.

I submitted two Issues and a PR that were all enthusiastically received and quickly acted on. In my experience, this openness to a newcomer is rare in large, established open source projects:

3 Likes

Thanks for chiming in @aeros and @dogweather!

W.R.T. the lack of formal rules, yes, the situation has to improve.

PyPA currently operates on an informal-consensus based model (“no one has blocking issues with this, so it’s OK”) for a lot of the things we do. We are working toward a governance model to make the decision processes and membership formal, and more transparent.

1 Like

It’s probably worth pointing out that the PyPA is a collection of projects, not of individuals1. So in one sense, the answer to @pitrou’s question is “Be a maintainer of a PyPA project”. As the PyPA explicitly does not have control over member projects’ governance, the rules on who is a maintainer for a particular project are at the discretion of that project.

1 I refrain from commenting on whether that’s obvious to people outside of the PyPA, and I don’t want to get into a debate on whether that’s the way it “should be”… :slightly_smiling_face:

1 Like

Yep yep.

All of these details are things that benefit from a clear document to point to saying: “this is how PyPA works” .

And, that’s literally the PyPA governance discussion. :upside_down_face:

2 Likes

Agreed, I just wanted to add some context for people not involved in / following that discussion.

2 Likes

The question then becomes: what are the formal rules for a project to become a “PyPA” project?

1 Like

As @pradyunsg said, that’s precisely the subject of the governance discussions.

1 Like

Not sure if this is off-topic, but there is an ongoing discussion about making improvements to Python packaging:

Perhaps that offers an opportunity to reduce some of the pain points related to this discussion?

Not sure why. Can you explain?

I vaguely recall there being two main threads in this discussion:

  • ambiguity surrounding PYPA (authoratativeness, participation, process)
  • pain points in packaging, relating to specific use-cases

Would the build step, i.e. building wheels, factor in to those pain points?

I don’t think it would, no.

The general ambiguity with PyPA might be fairly relevant to this topic, but the technical components of packaging or building wheels wouldn’t be.

I’ve tried to codify how PyPA functions today, into a formal governance model, that the PyPA can look into formally adopting.

Other than the voting mechanics (which are borrowed from CPython’s governance model), that’s basically how the PyPA functions today AFAIK. Maybe that document addresses some of the concerns that @pitrou has?

1 Like

FYI - @dustin just filed a PR to adopt the aforementioned governance model to be adopted as a PEP – https://github.com/python/peps/pull/1221/.