Yeah I think that’s what he meant. You don’t want CI editing commits.
I use pre-commit for this. It’s pretty decent. The major flaws I’ve found with it:
Each linter has to be in its own repo (for most linter types). So it’s not really usable for project-specific lints.
Doesn’t really work with e.g. pyright or pylint unless you use no third party dependencies because you need a venv set up with your dependencies installed and pre-commit (fairly reasonably) doesn’t take care of that.
Overall it’s good, with some flaws, but there’s nothing better available so you should definitely use it.
I’ve used pre-commit pretty extensively over the years and I’m confused.
Each linter has to be in its own repo (for most linter types). So it’s not really usable for project-specific lints.
Not sure what you mean by this. I have pre-commit set up to do linting in several different projects, and even have it running multiple differently-configured lint jobs in the same repo.
Doesn’t really work with e.g. pyright or pylint unless you use no third party dependencies because you need a venv set up with your dependencies installed and pre-commit (fairly reasonably) doesn’t take care of that.
Again, I have pre-commit set up on multiple repos running pylint with multiple different plugins. Pre-commit absolutely does take care of setting up venvs with needed dependencies.
Not sure what you mean by this. I have pre-commit set up to do linting in several different projects, and even have it running multiple differently-configured lint jobs in the same repo.
I don’t mean using lints, I mean writing custom ones. Say you have a custom lint you want to use but it only will ever be used for that specific project. You can’t just put the lint code in a subdirectory. It has to go in a separate repo.
Pre-commit absolutely does take care of setting up venvs with needed dependencies.
Again I think you might be misunderstanding. It will install pylint fine, but if your project does e.g. import yaml, it’s not going to set up a venv and install pyyaml for you.
Say you have a custom lint you want to use but it only will ever be used for that specific project. You can’t just put the lint code in a subdirectory. It has to go in a separate repo.
You can run locally defined hooks with pre-commit, just define them in the repo: local section of the .pre-commit-config.yaml, and have it run a bash/python/whatever script or something that invokes your custom linting, wherever it lives in your file structure.
It will install pylint fine, but if your project does e.g. import yaml, it’s not going to set up a venv and install pyyaml for you.
Yeah I misspoke/misremembered there. For Python based stuff, it uses the currently active virtualenv or your global python install, so it relies on you installing your own dependencies. Which isn’t really that big a deal imo, because you need to install those dependencies to run/debug/test locally anyways.
You can run locally defined hooks with pre-commit, just define them in the repo: local section of the .pre-commit-config.yaml
Sounds like you’re just googling it rather than actually speaking from experience. Suppose I have written a Python lint and it’s in my ci/lints/foo folder. How do I tell pre-commit that? (Hint: you can’t)
Which isn’t really that big a deal imo
For small Python projects, maybe not. The project I’m working on has multiple sub-projects and those each have their own venvs, pyproject.tomls, etc.
Sounds like you’re just googling it rather than actually speaking from experience.
Like I said, I’ve used pre-commit for multiple years now. If you can run your lints from a command line, you can configure pre-commit to run them.
The project I’m working on has multiple sub-projects and those each have their own venvs, pyproject.tomls, etc.
Monorepos definitely make things a bit trickier, but again, you absolutely can write a local pre-commit hook that runs a bash command or script that 1.) activates the necessary venv and 2.) runs the lint command. I know this because I’ve done it, multiple times.
Pre-commit hooks is a common approach to this, so that whatever is committed gets processed. Another possibility would be to set a bot on the repo to do automated commits after human-made ones, but that can get a little noisy.
sets the diff to ignore whitespace
Lines changed: 3
The pipeline should handle formatting. No matter how you screw it up, once you commit, it gets formatted to an agreed upon standard.
Or auto rejected when the format doesn’t fit.
Yeah I think that’s what he meant. You don’t want CI editing commits.
I use pre-commit for this. It’s pretty decent. The major flaws I’ve found with it:
Each linter has to be in its own repo (for most linter types). So it’s not really usable for project-specific lints.
Doesn’t really work with e.g. pyright or pylint unless you use no third party dependencies because you need a venv set up with your dependencies installed and pre-commit (fairly reasonably) doesn’t take care of that.
Overall it’s good, with some flaws, but there’s nothing better available so you should definitely use it.
I’ve used pre-commit pretty extensively over the years and I’m confused.
Not sure what you mean by this. I have pre-commit set up to do linting in several different projects, and even have it running multiple differently-configured lint jobs in the same repo.
Again, I have pre-commit set up on multiple repos running pylint with multiple different plugins. Pre-commit absolutely does take care of setting up venvs with needed dependencies.
I don’t mean using lints, I mean writing custom ones. Say you have a custom lint you want to use but it only will ever be used for that specific project. You can’t just put the lint code in a subdirectory. It has to go in a separate repo.
Again I think you might be misunderstanding. It will install pylint fine, but if your project does e.g.
import yaml, it’s not going to set up a venv and install pyyaml for you.You can run locally defined hooks with pre-commit, just define them in the
repo: localsection of the.pre-commit-config.yaml, and have it run a bash/python/whatever script or something that invokes your custom linting, wherever it lives in your file structure.Yeah I misspoke/misremembered there. For Python based stuff, it uses the currently active virtualenv or your global python install, so it relies on you installing your own dependencies. Which isn’t really that big a deal imo, because you need to install those dependencies to run/debug/test locally anyways.
Sounds like you’re just googling it rather than actually speaking from experience. Suppose I have written a Python lint and it’s in my
ci/lints/foofolder. How do I tell pre-commit that? (Hint: you can’t)For small Python projects, maybe not. The project I’m working on has multiple sub-projects and those each have their own venvs, pyproject.tomls, etc.
Like I said, I’ve used pre-commit for multiple years now. If you can run your lints from a command line, you can configure pre-commit to run them.
Monorepos definitely make things a bit trickier, but again, you absolutely can write a local pre-commit hook that runs a bash command or script that 1.) activates the necessary venv and 2.) runs the lint command. I know this because I’ve done it, multiple times.
Sounds like my love life …
Some diff tools don’t handle indentation by default.
So if you add a wrapper, it counts everything inside it as “changed”
That’s what “toggle whitespace diff” is for.
You can do that? How?
Pre-commit hooks is a common approach to this, so that whatever is committed gets processed. Another possibility would be to set a bot on the repo to do automated commits after human-made ones, but that can get a little noisy.
Haha! Jokes on you! It was mostly gnu makefile calls to ruby scripts!!! You’ve just broken the build a million different ways!
(Short for “The joke is on you”.)