Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add codespell (config, workflow, pre-commit) to detect new typos, fix found typos #540

Draft
wants to merge 9 commits into
base: master
Choose a base branch
from

Conversation

yarikoptic
Copy link

My humble contribution to make a world a better typo-free place

TODOs

  • remove custom workflow if precommit finds my typo (in TMP)

there were prior commits committing typo fixes, even one using codespell to detect. Now it would be automated.

@ptmcg
Copy link
Member

ptmcg commented Feb 14, 2024

This looks interesting. Please don't check/modify pyparsing_archive.py though. The code that should be checked is in the examples, tests, and pyparsing directories. I don't see where you define the .py files that should be checked.

@yarikoptic
Copy link
Author

By default it was by exclusion, not inclusion, i.e. it checks all text files (.py or not), and then we exclude some. It would be trivial to skip pyparsing_archive.py but are you sure should it be excluded?

  • prior commit to it 5353ccd was exactly that -- fixing typos identified by codespell
  • identified typos are legit

if it is not vendored code from somewhere else which might be subject to update and where typos should be fixed at the upstream project -- I do not see why it should not be fixed up.

Another interesting aspect is that I do not see you running precommit either through precommit "service" or github workflow since I did add pre-commit configuration, but it was only the codespell workflow I added which tripped on the injected typo. Should I may be replace codespell workflow with some workflow which runs pre-commit?

@ptmcg
Copy link
Member

ptmcg commented Feb 15, 2024

Never mind, I'm deleting the file. It was there as a security blanket for me while going through the breakup of the single-file release back during the pyparsing 2.x->3 transition, and I was still very unsure of myself that I might lose it out of git ignorance.

I can always get this from the 2.4.x branch (which I have locked in Github to prevent accidental loss or update to this code).

As for pre-commit, this is another case where I have been slow in adopting new tooling. It took me a while just to warm up to using black. Now I use pre-commit (with black, isort, flake8 and others) at work and rely on it heavily. If you want to open a PR that adds pre-commit as a Github workflow, that works great for me.

=== Do not change lines below ===
{
 "chain": [],
 "cmd": "git-sedi comparitor comparator",
 "exit": 0,
 "extra_inputs": [],
 "inputs": [],
 "outputs": [],
 "pwd": "."
}
^^^ Do not change lines above ^^^
=== Do not change lines below ===
{
 "chain": [],
 "cmd": "codespell -w",
 "exit": 0,
 "extra_inputs": [],
 "inputs": [],
 "outputs": [],
 "pwd": "."
}
^^^ Do not change lines above ^^^
this particular setup borrowed from lark's mypy workflow
@yarikoptic
Copy link
Author

I have force pushed now with the pre-commit workflow -- please bless it to see if works ok

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants