cherrypy
Adopt jaraco/skeleton
Docs builds are failing and I don't know why. There are a ton of errors and warnings, but many of those errors and warnings are also in main, so many that it's impossible to see what's newly broken.
Oh, I bet the problem is that the skeleton doesn't allow for warnings to exist in the docs build.
Could you please not introduce black? Can't stand it.
I don't particularly care for some of the choices that black makes. It is, for better or worse, the most popular autoformatter, and so by adopting it, I adapt to those choices made and rely on the tool to automatically reformat the code so that when a style choice is missed, it's readily and automatically corrected.
By applying some standard for the code, it makes it easy not to get wrapped up in bikeshedding about what is the preferred style and to avoid nitpicks when reviewing code, and instead to focus on the impactful changes.
Personally, I believe there is art to code and automatic formatters take a lot of the creativity out of the process, but the benefits far outweigh the costs. To not adopt an autoformatter would mean someone would need to accept the burden of fielding and reconciling conflicts around style choices and the project would need to accept the burden that puts on the development velocity. Accepting black removes one major concern from the contribution process.
Can you elaborate more on what it is about black you find distasteful (either here or perhaps in a more permanent location like a blog)?
I'm having difficulty getting the Windows jobs on GHA not to stall.
From what I see, the Windows jobs are getting cancelled because of macOS. Do you have any other logs?
P.S. If you need to SSH into workers, https://github.com/marketplace/actions/debugging-with-tmate now supports Windows too.
Could you please not introduce black? Can't stand it.
I don't particularly care for some of the choices that black makes. It is, for better or worse, the most popular autoformatter, and so by adopting it, I adapt to those choices made and rely on the tool to automatically reformat the code so that when a style choice is missed, it's readily and automatically corrected.
I'm not against the idea of formatters in general but I hate that when they stand in a way, people are forced to just live with it. It just generates of resistance throughout the development process when one wants to express the code intent through structuring it. Among other things, the opinionated bit is the worst. In particular, when I write fully PEP8-compliant code, I hate that it reshuffles everything removing any traces of the intent that code is supposed to communicate. I must know, I tried to adopt black multiple times and couldn't stomach it each time 🤷.
It'd be much better if a formatter only corrected bits that cause linter violations. I would be more open to using less intrusive tools like autopep8 that don't attempt to change any PEP8-compliant code. I've actually tried it out, it produces formatting that is similar to the black's one but doesn't have most of its drawbacks.
Another annoying bit is that the default line-length is not accessibility-friendly, nor does it aid readability. Long lines create non-inclusive environment for folks like me having large fonts. Also, they tend to prevent comfortable use of vertical panes or viewing side-by-side diffs. Last but not least, code is text and so readability considerations are similar to the typographic ones: https://stackoverflow.com/a/71182458/595220. It's worth noting that the typography studies recommend lines length somewhere between 50-75 chars: https://baymard.com/blog/line-length-readability. Black is making the lines longer when it's really better not to. Having it in the enforced toolchain doesn't let people to take advantage of a smarter approach to lint the line length (allowing a small amount longer lines where needed while having most of the lines under a set limit), like this great plugin implements: https://github.com/orsinium-labs/flake8-length. This is why I'm in the 79 char lines camp.
Another problem with autoformatting (in general, I guess) is that I noticed it inspires people to be careless about structuring their code and analyzing readability problems. One prominent example is formatting that targets shorter lines. One could think that it's good that it takes away the burden of fixing corresponding linting violations. But then, it actually brings more harm than good. You see, a linting violation about a long line could (and arguably should!) trigger a thought process, an analysis of why a certain line got long. More often than not, the underlying reason is a bizarre level of code block nesting. What's the correct solution? Looking at a broader picture/surrounding code and restructuring it to have less nesting which usually entails some nice refactoring as a side-effect. What does black do? Not that. It multilines stuff unnecessarily, implicitly, silently. Is this useful? Well, the linting violation is gone. But does the code gain readability? Most of the time it becomes less maintainable so no, absolutely not. I'm pretty sure that this reduces the usefulness of the linters even.
Another interesting bit is that it adds an extra green checkmark among the linting outputs re-ensuring folks that the code is "good" when it's not, it's just formatted. I can see how newbies could take this as a quality metric which isn't helpful either.
By applying some standard for the code, it makes it easy not to get wrapped up in bikeshedding about what is the preferred style and to avoid nitpicks when reviewing code, and instead to focus on the impactful changes.
I agree that having a style is good and having a reasonably set up formatter (like autopep8, which I've vetted in the past) would be nice. Still, I'd like that tool not to work against me (hence, it shouldn't be black) and be inclusive towards the contributors.
The nitpicking point has been brought up in the context of code reviews countless times. I do agree that it shouldn't be happening. Although, one person's nitpicking is another person's attempt to improve readability. I feel like this argument is often being misused. I've seen a lot of times that suggestions to restructure something (because it's too nested or uses single-letter variables) are taken as "formatting change request" and labeled as style changes (even though they aren't). So yes, while I've been blamed for nitpicking on the style a lot, more often than not, it was me trying to improve readability from the structural perspective and not the style one. This happened even when I explicitly stated that the intent is not style-related and that I actively avoid making style comments. I think most of this needs to be fixed on the social level, with code review guidelines rather than being a technical solution — the latter just won't work for this specific argument. Having autopep8 (which I suggest we use instead) would help partially but I don't believe that it solves the communication problem.
Personally, I believe there is art to code and automatic formatters take a lot of the creativity out of the process, but the benefits far outweigh the costs. To not adopt an autoformatter would mean someone would need to accept the burden of fielding and reconciling conflicts around style choices and the project would need to accept the burden that puts on the development velocity. Accepting black removes one major concern from the contribution process.
Totally agree about the creative process, although I'm sure that the creativity bit is not as important as being able to communicate the intent in code, which it does take away as a side-effect. As I've outlined in the paragraphs above, having black just replaces one concern with another. Having autopep8 would be preferable.
In fact, fighting black has brought me so much negativity that it gives me anxiety almost every time I have to face it. This makes me to avoid contributing to projects where I'd send a PR without even thinking otherwise. I make exceptions sometimes, but the more I'm forced to interact with this tool, the more it drives me away. Every single time.
Can you elaborate more on what it is about black you find distasteful (either here or perhaps in a more permanent location like a blog)?
I guess I've answered the questions above. I was thinking about writing a post and maybe in the future I will but I get a writers block a lot which is why it's hard for me to finish writing articles. Also, I've got a lot on my mind lately and even been away from work and FOSS for a while. I'm just returning to work and I can't imagine having mental capacity to write a constructive blog post not filled with pure hate. So I should probably refrain.
P.S. Thanks for taking care of the CI. It's been on my list for quite a while and I've been exploring ways of maintaining it with reusable components and something similar to your skeleton project. The effort is on hold, obviously but I hope I'll be able get to it at some point.
I'm abandoning this work, as it seems CherryPy has evolved too far from the upstream expectations for it to be useful.
I am exploring replacing black with ruff --format, but I haven't yet made the move.