Python gets a "Developer-in-Residence"

Posted Aug 2, 2021 7:56 UTC (Mon) by massimiliano (subscriber, #3048)
In reply to: Python gets a "Developer-in-Residence" by mathstuf
Parent article: Python gets a "Developer-in-Residence"

This is why, IMO, code formatting should be enforced at the integration time rather than development time (such as as a commit hook).

I have a slightly different take on this.

IMHO, CI should never rewrite (reformat) your code, it should just fail the build if it is malformed (just like if a test failed).

What commit hooks should do, instead, is run tools that are in sync with whatever CI is doing on that branch, so that they will not introduce failed builds. I usually achieve this making so that every dev has the "official" development environment available using docker, the Dockerfile is in the repo, and the scripts that the developer (or commit hook) uses run the same tools that CI runs (because CI ultimately uses the same Dockerfile: it's in the repo).

Keeping the Dockerfile in the repo is what keeps CI and the dev env in sync. It is a technicality, an implementation detail, but the general principle is to specify the development tools unambiguously and make so that both developers and CI use exactly the same tools at every commit by keeping that specification in the same repo as the code. Often using docker is a practical way to do it, but of course, others are possible.

Python gets a "Developer-in-Residence"

Posted Aug 2, 2021 11:42 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

CI doesn't *automatically* do it. You need a `Do: reformat` command (so you can plan for it at least).

> it should just fail the build if it is malformed (just like if a test failed).

Given how unsure many developers are with `git rebase -i` and resolving intra-branch conflicts due to reformatting, this will just end up littering the history with useless "fix clang-format" commits instead of people integrating the diffs back into the appropriate commit.

> I usually achieve this making so that every dev has the "official" development environment available using docker

That assumes you can even *have* an "official" development environment. It also doesn't consider non-Linux platforms at all.

> run the same tools that CI runs (because CI ultimately uses the same Dockerfile: it's in the repo).

One of the design decisions we had when making our workflow tool (ghostflow) is that *no* code in the repo is trusted, so none of it is executed (be it in a Dockerfile or no). It can indicate *what* to run (e.g., "file X uses clang-format-9, but file Y is third party code, so ignore it"), but how it is run is in the workflow deployment, not the repository.

> Keeping the Dockerfile in the repo is what keeps CI and the dev env in sync. It is a technicality, an implementation detail, but the general principle is to specify the development tools unambiguously and make so that both developers and CI use exactly the same tools at every commit by keeping that specification in the same repo as the code. Often using docker is a practical way to do it, but of course, others are possible.

We're not making a *product*, so there's not "one build" that is blessed. We get bugs about it not working on Windows, macOS, Arch, Fedora, Ubuntu, HPC deployments, weird MPI deployments, vcpkg, etc. A diverse development base helps flush things out that we just can't test for.