codespell: move and adjust configuration to pyproject.toml, fix few new typos#1392
codespell: move and adjust configuration to pyproject.toml, fix few new typos#1392yarikoptic wants to merge 4 commits intolark-parser:masterfrom
Conversation
…commit Centralization of configuration would let use codespell just as is without pre-commit. Also it seems that new typos were found -- adding one more skip
=== Do not change lines below ===
{
"chain": [],
"cmd": "codespell -w",
"exit": 0,
"extra_inputs": [],
"inputs": [],
"outputs": [],
"pwd": "."
}
^^^ Do not change lines above ^^^
| For anything else, I can be reached by email at erezshin at gmail com. | ||
|
|
||
| -- [Erez](https://github.com/erezsh) | ||
| Installating |
There was a problem hiding this comment.
See the TODOs above ;) it was added explicitly in a commit to see if you do pre-commit checking some how (e.g. via github integration or workflow). Apparently you do, but in a Python type check and not a dedicated workflow.
So in principle I can remove dedicated workflow here OR separate our "Python type check" into two -- 2nd one would just run pre-commit and have a clear/different name. WDYT?
There was a problem hiding this comment.
What would you say are the pros and cons of each approach?
There was a problem hiding this comment.
Having dedicated codespell action makes it clear/easy to find what failed the CI since name of it (codespell) says it all. When it is bundled in another action (pre-commit) - it not immediately clear. If it is bundled somehow in Python type check then it becomes even misleading.
I personally would have
- removed codespell action (duplicates what pre-commit does anyways)
- separated pre-commit into a dedicated workflow: it is expected for it to never fail since it is expected that it would be ran by contributors locally first. And even if it fails -- it is "low priority" since typically only formatting etc aspects, and thus even lower than "Type Checking"
There was a problem hiding this comment.
And I am not too familiar with the https://pre-commit.ci/ service to advice on that
There was a problem hiding this comment.
Well, one big disadvantage with your proposal is that now instead of only having to run pre-commit, which can run automatically before each commit, contributors would have to run two things, the second one manually. They would only see the error after they open a pull request, instead of seeing it locally when they try to commit.
@MegaIng What do you think?
There was a problem hiding this comment.
We might be misunderstanding... I added pre-commit for codespell, nothing to be ran manually
There was a problem hiding this comment.
Try to add new popular typo!
2 participants
Best to have configuration(s) in central place so people could just use
codespellwithout pre-commitTODOs