On Saturday, 31 December 2022 at 08:56:34 UTC, Richard (Rikki) Andrew Cattermole wrote:
>I don't see how it would differ, the format is a new commit as part of the PR.
See: https://mskelton.medium.com/auto-formatting-code-using-prettier-and-github-actions-ed458f58b7df
OK, understood. (It wasn't 100% clear from your previous post that you were envisioning one follow-up patch on top of the PR, as opposed to modifying patches in the PR.)
>You've got the problem right there. There is no tool to run locally. Its mixed between a few different CI runner types.
Yeah, I see why that would be very painful.
What I'd like to suggest is that, regardless of what one does or doesn't do during CI, the absence of a single tool for checking or fixing style is the crux of the problem. Whatever CI does or doesn't do, it's IMO useful as a developer to be able to check one's own code for style correctness, before submitting in a PR.
So it seems to me that the best way forward here is to make sure that all the wanted style checks can be carried out by a single tool, or at least by a well defined set of tools with standardized configuration.
There are good examples in other languages. I've historically preferred tools that just define what's objectionable rather than what's correct (if that makes sense), so there is still an amount of flexibility for the developer to write code as they wish, but since I discovered the Python tool black
, I think it's clear that it's at least possible to craft a deterministic formatting tool that consistently produces good looking code.
What's particularly nice about that tool is that it can be run to edit code in-place, or it can be used in a dry-run mode which outputs a patch showing what would have been changed (with exit code 0 if that's nothing, or 1 if changes are required).
Where CI for my own projects is concerned, I've preferred to use the dry-run mode and throw it back on the PR author to actually make the fix -- on the grounds that the PR author should be in control of what code changes, but also because it's straightforward to follow what changes are wanted, and equally trivial to run the tool locally to make them. But obviously one could use the same tooling to append a style-fix patch to a PR, if that was considered desirable.
>People (including myself) spend time having to figure out why the CI failed, rather than letting it fix any problems it encounters. It adds a failure mode to contributing, when we could eliminate it and have more consistent code as a result!
I completely agree that we want to eliminate this kind of uncertainty. I just think that to achieve it we need a well-defined tool which can be run locally as easily as in CI.
Python tooling is particularly instructive as a good point of reference, because there are other tools (e.g. tox
) which make it very easy to run a range of different checks (style, linter, test suite, ...) in a standardized way, via a single command.
Of course, it's not like people haven't already tried (dfmt
etc.). It just seems to be hard to sustain the momentum to implement and maintain such tools for D :-(
I'll mention some of these thoughts in the feedback I plan to write to Mike.