GH-109408: Add a make lint target

[AA-Turner]

I am almost certainly not the best person to do this, given I use Windows and I am not confident in testing changes to the Makefile.

However, this is a sketch of a solution to adding a make lint target, as discussed in on Discourse and related to #109895.

Please feel free to push to this branch if you have improvements / spot glaring errors.

A

• Issue: Move Azure Pipelines CI to GitHub Actions #109408

[encukou]

Who vouches for the security of the software that make lint will install on my machine?

[erlend-aasland]

Who vouches for the security of the software that make lint will install on my machine?

It is installed in a virtual environment. We already require folks to install third-party dependencies for extension module, not to mention various compiler toolchains for building.

[encukou]

Yup. For pip & setuptools it's PyPA; for compilers it's (for me) the distro. Here it's harder to keep up.

[AA-Turner]

Repeating Greg's comment from the Discourse thread re naming:

What I could potentially imagine as nicer than make patchcheck or make lint is actually make push… that runs meaningful checks that must pass prior to doing a git push of my branch to a git repo name of my choosing.

[AA-Turner]

Who vouches for the security of the software that make lint will install on my machine?
...
For pip & setuptools it's PyPA; for compilers it's (for me) the distro. Here it's harder to keep up.

I think there are a couple of approaches we could take here. One is to use the pre-commit binary from the OS if it is installed, which allows you to trust your OS distribution (e.g. fedora, debian, gentoo). Another is to pin the version of pre-commit, and require a committer to update the pin. A third is to vendor pre-commit within CPython's source tree.

On a more philosophical level, I'm not sure the level of assurance we can provide -- to take the PyPA per your example, they provide a high level governance framework, rather than managing individual projects. A good example might be the documentation, where we pull in Sphinx, sphinxext-opengraph, sphinx-notfound-page, and many dependencies. There is no CPython assurance of any of these projects (beyond perhaps 'blurb' and 'python-docs-theme').

My proposal would be to use an OS-provided binary if it exists, which would also benefit in avoiding a venv if the user has pre-commit globally installed. Would this alleviate your concerns?

A

[hugovk]

Also it is not required to install it locally, it runs on CI in any case.

[erlend-aasland]

Also it is not required to install it locally, it runs on CI in any case.

Yep. You don't need to install this, @encukou; it's optional :)

[encukou]

use the pre-commit binary from the OS if it is installed

The pre-commit binary is one thing. Another is the individual linters. They are installed from mutable tags on GitHub, and AFAIK, we don't have a policy for adding new ones or updating existing ones.

to take the PyPA per your example, they provide a high level governance framework, rather than managing individual projects.

Right, I said PyPA for short. The long story is that pip and setuptools are maintained by specific PyPA members, with (usually) close ties to the core dev team.
Still, it's something to keep in mind as a potential attack vector for getting into core devs' (and contributors') systems.

documentation, where we pull in Sphinx, sphinxext-opengraph, sphinx-notfound-page, and many dependencies

Yes. That's another place where I think we could improve handling the security implications.

You don't need to install this, @encukou; it's optional :)

Sure, I'm not really planning to use this.
But, while we're all used to pip downloading code from the 'net, having a make command do that is much more surprising -- at least to me.
[edited to add:] It feels like CPython should vouch for the security of its make targets.