Skip to content

Add codespell to CI. #206

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

Merged
merged 1 commit into from
Oct 27, 2020
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Empty file added .codespellignore
Empty file.
11 changes: 10 additions & 1 deletion README.md
Original file line number Diff line number Diff line change
Expand Up @@ -92,7 +92,16 @@ To format code:

Note that you may have to use `yapf3` explicitly depending on your environment.

You can also run the `./scripts/test` script to check flake8 and yapf.
To check for spelling mistakes in modified files:

```
> git diff --name-only | xargs codespell -I .codespellignore -f

You can also run the `./scripts/test` script to check for linting, spelling, and run unit tests.

### Continuous Integration

CI will run the `scripts/test` script to check for code quality. If you have a Pull Request that fails CI, make sure to fix any linting, spelling or test issues reported by `scripts/test`.

### Documentation

Expand Down
1 change: 1 addition & 0 deletions requirements-dev.txt
Original file line number Diff line number Diff line change
@@ -1,3 +1,4 @@
codespell==1.17.1
ipython==7.16.1
jsonschema==3.2.0
pylint==1.9.1
Expand Down
10 changes: 10 additions & 0 deletions scripts/test
Original file line number Diff line number Diff line change
Expand Up @@ -23,6 +23,16 @@ if [ "${BASH_SOURCE[0]}" = "${0}" ]; then
# Code formatting
yapf -dpr pystac tests

# Code spelling
codespell -I .codespellignore -f \
pystac/*.py pystac/**/*.py \
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not just do dirs? It looks like you are leaving out the test data. There are only a few things needed for the codespellignore for the test data.

codespell -I .codespellignore -f docs pystac scripts tests *.py *.md

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Trying to just specify directories was including things like docs/_build/html/_static/jquery.js and .ipynb_checkpoints and __pycache__ files for me, and throwing a lot of warnings about binary files.

Does that command cleanly for you?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

codespell on my machine doesn't seem to pay attention to .codespellignore, but if you add --skip _build,__pycache__, that seems to work for me minus the two examples files.

codespell --skip _build,__pycache__ -I .codespellignore -f docs pystac scripts tests *.py *.md
tests/data-files/examples/gee-0.6.2/catalog.json:18: ACI ==> ACPI
tests/data-files/examples/gee-0.6.2/catalog.json:438: ALOS ==> ALSO
tests/data-files/examples/gee-0.6.2/catalog.json:443: ALOS ==> ALSO
tests/data-files/examples/gee-0.6.2/catalog.json:448: ALOS ==> ALSO
tests/data-files/examples/gee-0.6.2/catalog.json:453: ALOS ==> ALSO
tests/data-files/examples/gee-0.6.2/catalog.json:2218: NED ==> NEED
tests/data-files/examples/sentinel-0.6.0/sentinel-2-l1c/9/V/catalog.json:1: UE ==> USE, DUE

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Skipping the directories mentioned worked for avoiding those files, but it ended up picking up my venv files. Also I'll note that I don't think spell checking the data-files is necessary; misspellings from other folk's STAC is harmless and wont' affect tests. I think approach this as being explicit about what we want to include rather than doing everything but specific excludes will make for a better experience.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Really either way is fine and gets the project better coverage than now. Personally, I'd check the data files too. Errors cause friction in unexpected ways for in different circumstances and tend to propagate via copy paste, but these are unlikely to cause too much trouble.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense. I think keeping it to code and documentation works for now, and we can expand it if we see we're running into situations where we wish we were spell checking stacs that are brought in.

Can you move your review to Approved if this is resolved?

tests/*.py tests/**/*.py \
docs/*.rst docs/**/*.rst \
docs/*.ipynb docs/**/*.ipynb \
scripts/* \
*.py \
*.md

# Test suite with coverage enabled
coverage run --source=pystac/ -m unittest discover tests/
coverage xml
Expand Down