Repositories under the "python" organization on GitHub #9
Comments
|
First, I see Black as a good move into the Python org, and I assumed from the Language Summit that the move would happen. Black's already a de facto standard tool to simplify diffs for code review and formatting. It's been used on the devguide for 8 months with no issue. Like typing, it is optional but sensible for folks who wish to adopt it into their workflows. Going forward, it seems reasonable to have:
We faced similar concerns about the Jupyter org a couple of years ago. We created an incubator process for projects that were not driven by a core team member. For projects maintained by a core team member, projects were moved and announced if a sub org, like JupyterHub, saw benefits of the move and were willing to maintain. If the project were to impact folks in multiple Jupyter sub orgs, we would do an informal poll of the steering council. |
I don't anymore. Due to the tweet involved. My problem with things being under the Python org on Github is that it now unwittingly blesses them as some form of official PSF supported thing. This was effectively the wording used in @ambv 's tweet announcing the Black repo move that has been picked up by tons of others blindly assuming it is true. quoting the text: "Black, your uncompromising #Python code formatter, was a project created with the community in mind from Day 1. Today we moved it under the PSF umbrella. It's now available on GitHub under https://github.com/python/black/ ." :( I read "moved under the PSF umbrella" as implying an endorsement that is not true! This felt to me like shameless self promotion of the Black project by attaching the PSF name to it despite the PSF not actually endorsing Black or even owning any rights to it. I consider that poor form and thus am reacting negatively. Had this been done without ever claiming that living under /python/ had meaning I would not have cared in the same way I didn't care that MyPy moved to host it's code there. What does the PSF have to do with Black? Nothing really, we're just users. A project living within an org implies special status. If we're going to allow a project to claim that as a status, it seems like something the python org owners (steering council? PSF board?) should be deciding. Alternatively we need to make clear that there is no such status by living under the /python/ org. Black isn't alone. Under this logic of seeing /python/ be used to imply a conferred official PSF endorsement (how I read "under the PSF umbrella") to a project, I have a similar problem with MyPy living under the Python org on Github. Someone else could now make incorrect assumption that living there implies status. So lets please clarify what /python/ status actually is, publicly document it, and act accordingly. I don't mind things living within the org if that is what is decided, but I do feel like we now need to call out what is and isn't an official PSF owned project. Most everything else under github.com/python/ seems directly related to the PSF's interests (I'm unsure about a couple others) in CPython and things directly related to it's development or common Python infrastructure (bots, various websites, some pypi stuff, infrastructure stuff, typeshed). Why else do I care so much? Black is not the only widely used actively developed Python auto-formatter. yapf is actively used and developed; it predates black, but black chose to implement different opinions instead of work with the existing good formatter. They've both got great output, just different. Unless we choose the golang route and require formatted code in Python 5 (disruptive, unlikely), we shouldn't endorse a particular formatter. Just endorse the concept of auto-formatting. There are plenty of non personal account places to land a repo. |
Thanks @gpshead. I'm assuming that the tweet, though perhaps could be better worded and incorrectly overstated what it means to be hosted in the python org, was sent and the move was done with good intentions. I agree that better clarity around what hosting a project under the python org means is needed. Does it mean official, ownership, and endorsement? I'm not sure. At minimum, I view it as a commitment for members of the CPython core team to maintain a widely used, beneficial tool for Python development. If Google wished to transfer yapf to the python org, I would have no objection to that. I agree that it is important to add guidelines about what hosting in the python org means and how to transfer a project to the python org. Let's get to the other side of PyCon and discuss within the steering council and the PSF infrastructure team and add some specifics around the topic. I would propose for now that Black is being incubated in the Python org for a period of six months while more formal policies / guidelines are discussed. |
|
@gpshead wrote:
What is "github.com/python" if not an umbrella organization? What entity provides us with this umbrella and is ultimately responsible for it if not the PSF? How would you suggest I word it? Since tweets must be brief and language is ambiguous, the tweet has two parts, I made sure the other one explicitly states:
@gpshead wrote:
This is off topic for this issue but it's also not true so let me briefly explain. Three years before creating Black I contributed a similar style to YAPF but ultimately YAPF's design and behavior made a wide rollout at Facebook impossible. |
|
I still believe that Black belongs under PyCQA.
On Sat, May 4, 2019 at 09:10 Łukasz Langa ***@***.***> wrote:
@gpshead <https://github.com/gpshead> wrote:
It now unwittingly blesses them as some form of official PSF supported
thing. This was effectively the wording used in @ambv
<https://github.com/ambv> 's tweet announcing the Black repo move
What is "github.com/python" if not an umbrella organization? What entity
provides us with this umbrella and is ultimately responsible for it if not
the PSF? How would you suggest I word it? Since tweets must be brief and
language is ambiguous, the tweet has two parts
<https://twitter.com/llanga/status/1123980467911495680>, I made sure the
other one explicitly states:
Q: Does it mean it's official now?
*A: No, just like mypy isn't.*
Q: Does it become a "de facto" standard?
A: Maybe. That's really up to you, users.
@gpshead <https://github.com/gpshead> wrote:
yapf is actively used and developed; it predates black, but black chose to
implement different opinions instead of work with the existing good
formatter
This is off topic for this issue but it's also not true so let me briefly
explain. Three years before creating Black I contributed a similar style
to YAPF
<google/yapf@9408987>
but ultimately YAPF's design and behavior made a wide rollout at Facebook
impossible.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#9 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAWCWMQYIQHJOJVG5I7ODR3PTWDNJANCNFSM4HKVGHAQ>
.
--
--Guido (mobile)
|
|
I agree with Gregory and Guido.
When was this discussed? If I remember correctly, we have a policy of declining cosmetic-only fixes. See https://bugs.python.org/issue36571 for a quite recent example.
Right, but this doesn't mean we can move our personal projects to Python organization. I'm a maintainer of a popular AST library which is used by big companies (including one from big four) and open source projects. I can easily use it in one or two projects in the Python organization. Should I move it? Absolutely no. I didn't even move https://github.com/berkerpeksag/cpython-emailer-webhook (note that it was written for python/cpython) because I thought it's not qualified to live under the Python organization. |
|
@ambv knows that I disagree with many of the decisions Black makes. Perhaps that makes me biased, but I do agree with @gpshead that putting it under the python organization is implicit endorsement, and while I don't at all fault Black for being opinionated, I don't endorse its opinion about how Python code should be formatted. So question: once it's under the python organization, does that mean that its opinions are now open to change if done by consensus? Or does it mean that more things can be made configurable to allow for more personal choice? Who gets to decide? I'm willing to have a better conversation about it, and the future policy for other projects, but right now I agree with @gvanrossum that it probably better resides within PyCQA. |
The latter - configurable per repo - is the only good way forward for formatters if we want to encourage mass adoption without generating needless churn and pain. But that is off topic for this issue which should just focus on repos under the "python" org. |
I think it is fair for a couple very recent modules in the stdlib to adopt use of a formatter and try it out within our CPython workflows. From experience in a huge codebase, it works quite well. There are really no cosmetic-only fixes when you use a formatter beyond the one time initial setup formatting. Why? In future changes, automate running the formatter on formatter covered code in "only format changed lines" mode. So that the rest of the file isn't reformatted as the formatter evolves as a side effect within unrelated changes. I don't currently use black so I don't know if it supports this yet, but in yapf it's the --lines argument, you automate passing it the line ranges from the current diff and it'll try to avoid making changes well outside of that range. |
|
Raised psf/black#830 to suggest implementing --lines or similar. |
|
Another instance of a user taking the move as an official endorsement PyCQA/pycodestyle#373 (comment) |
|
I think the question this has brought up is whether we want to take an Apache-like umbrella project approach for the Python organization or whether it's going to be strictly for CPython and things directly related to it and the language. If we decide to do the former then we should decide roughly what we want from a project to consider bringing them into the Python org and be clear of this fact that we are planning to treat the org that way. If it's the latter then clarification should be gained about how to justify why mypy gets to be included since there are other libraries and tools which implement PEPs that are not in the Python org, else I think we should move mypy out so it isn't getting special treatment (and that shouldn't break things as URLs should redirect as appropriate). I will say that being under the Python org brings PSF-specific benefits. For instance, it puts the project under the PSF Code of Conduct. It also gives Black access to the PSF's org benefits for things like CI which are often granted at the org level (and not the repo level). As for the "it should be in PyCQA", I think that's a bit distracting by specifying where we think it should go as that can lead people to think the impact is less if we don't have Black under the Python org. PyCQA is not under our purview nor is it under the PSF's purview, and so this really is a yes/no discussion of whether Black should be allowed under the Python organization in my mind. |
|
My suggeestion would be to allow the I don't think that being part of these orgs mean that they are official/blessed solutions, but rather it's more about disaster recovery, project longevity, and infrastructure concerns. For instance, if a project such as black is worried "hey I'm kind of becoming important for a lot of projects, but the sole developer might have something happen and I want to protect against that". Putting something under the I think that some people will take it to mean it is official, but I wouldn't be very worried about that personally. In my experience, people take all sorts of random signals to suggest that something is blessed/official (I've had people take out of context tweets of mine as evidence for instance) and it's basically impossible to prevent it from happening. I think it is good though to document what exactly is inferred from being a member of this org, and what the rules and what powers you give up from doing so. As far as PyCQA and other such umbrella orgs go... I honestly think that the PyPA is really the only other umbrella org that makes sense to consider right now. Not to knock anything anyone else is doing, but like the PyCQA is, to my knowledge, owned by one person who isn't even involved in the Python community anymore. While the PyPA isn't directly under the PSF, it has working relationship already where it sort of falls under the PSF while still being largely distinct. It's really the only other umbrella org out there that is anything like |
|
The council voted last night and the decision was to keep the Python org for Python itself, ancillary repos, PEP reference implementations, and related tooling: python/devguide#480. |
On Thursday, May 2nd, I moved the Black project from ambv/black on GitHub to under the "python" organization. Nick Coghlan raised concern that there is a missing standard for what kinds of projects fit under "python" and a missing process for moving an existing project to it. It's also as of yet unclear what kind of governance under the PSF-provided "python" organization on GitHub should the Steering Council hold. I'm creating this issue to track those questions.
python/black
Since moving Black triggered this issue, I'd like to take a moment to explain how we arrived at it.
What is Black?
Black is an opinionated code formatter implementing a subset of PEP 8. Over the past 14 months of its existence, it took the Python world by storm. It's got three times the stars on GitHub as autopep8, and surpassed YAPF in monthly downloads from PyPI.
It's now used by notable open-source projects like pytest, tox, Pyramid, Django Channels, Hypothesis, attrs, Poetry, PyPA applications (Warehouse, Pipenv, virtualenv), Pallets libraries (Werkzeug, itsdangerous, MarkupSafe), and many others. Popular editors for Python like Visual Studio Code and Mu ship with Black formatting by default. Mercurial introduced support for tool-aware merges with Black in mind. In fact, there is a DEP to format the entirety of Django with Black. Twisted and Flask are interested in adopting Black during the PyCon sprints.
What is the case for Black living under "python"?
Black is already used in the development of CPython. The new pgen created by Pablo is formatted with Black. Maintainers of dataclasses and asyncio in the standard library are interested in having their libraries auto-formatted. To start off, I'm going to set up the required infrastructure for this during PyCon sprints with configparser being the first auto-formatted module in the standard library.
I felt that keeping the tool under a personal account on GitHub was wrong. First, it's a risk in case if I suddenly could not continue development. It also makes other contributors feel less ownership over the project. Finally, it creates unproportional focus on the creator versus the project.
The mission of the tool is to accelerate development with Python by solving bikeshedding over formatting and creating consistent results with minimal diffs. One of the successful innovations of the Go programming language was the introduction of "gofmt", a formatting tool with a similar goal that was easy to find and ready to use out of the box. Having an established tool like this for Python was a wish of many programmers, myself included.
There is precedent under "python" in the form of Mypy which is a tool with a separate set of core developers, advertised as optional, and not treated as an official type checker.
Did you ask?
Yes, I talked with many core developers in person during the sprint at Microsoft. I asked the room at the Language Summit, with all Steering Council members in attendance. In both cases, the reaction was rather indifferent and no strong objections were raised.
Additionally, core developers are authorized to create (and thus move) repositories within the "python" organization on GitHub.
The text was updated successfully, but these errors were encountered: