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

style: add ruff and black to pre-commit #1459

Merged
merged 7 commits into from Jul 18, 2023

Conversation

d-v-b
Copy link
Contributor

@d-v-b d-v-b commented Jul 12, 2023

This PR is a prelude to reformatting the codebase with ruff and black linters. .pre-commit-config.yaml and pyproject.toml have been modified to add + configure ruff and black (and remove flake8).

A subsequent PR will contain the styling changes.

TODO:

  • Add unit tests and/or doctests in docstrings
  • Add docstrings and API docs for any new/modified user-facing classes and functions
  • New/modified features documented in docs/tutorial.rst
  • Changes documented in docs/release.rst
  • GitHub Actions have all passed
  • Test coverage is 100% (Codecov passes)

@github-actions github-actions bot added the needs release notes Automatically applied to PRs which haven't added release notes label Jul 12, 2023
@d-v-b
Copy link
Contributor Author

d-v-b commented Jul 12, 2023

😵‍💫 it looks like the code gets automatically styled by github actions after modifying the pre-commit config, so it's not possible to separate the config changes from the styling itself in separate PRs.

@codecov
Copy link

codecov bot commented Jul 12, 2023

Codecov Report

Merging #1459 (fd144c4) into main (8fc3b4b) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##              main     #1459   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           37        37           
  Lines        14723     14723           
=========================================
  Hits         14723     14723           
Impacted Files Coverage Δ
zarr/context.py 100.00% <ø> (ø)
zarr/tests/test_meta_array.py 100.00% <ø> (ø)
zarr/tests/test_storage.py 100.00% <ø> (ø)
zarr/__init__.py 100.00% <100.00%> (ø)
zarr/_storage/absstore.py 100.00% <100.00%> (ø)
zarr/_storage/store.py 100.00% <100.00%> (ø)
zarr/_storage/v3.py 100.00% <100.00%> (ø)
zarr/_storage/v3_storage_transformers.py 100.00% <100.00%> (ø)
zarr/attrs.py 100.00% <100.00%> (ø)
zarr/convenience.py 100.00% <100.00%> (ø)
... and 24 more

@d-v-b
Copy link
Contributor Author

d-v-b commented Jul 12, 2023

I'm not sure what to think of the pre-commit-ci bot. I feel like linting should be part of the checking process, not automatically applied via automated commits. At least for this PR, automatically running pre-commit is very wrong, because I deliberately did not commit the files that the bot modified.

edit: it also seems like the bot is not running pre-commit in the same way as in my local environment. When I execute pre-commit run --all-files on the commit produced by the bot, pre-commit fails.

local pre commit run

(zarr) ➜  zarr-python git:(ruff_black_prelude) pre-commit run --all-files
black....................................................................Passed
ruff.....................................................................Failed
- hook id: ruff
- exit code: 1

zarr/_storage/absstore.py:52:101: E501 Line too long (141 > 100 characters)
zarr/_storage/v3.py:18:5: F401 `zarr._storage.store._listdir_from_keys` imported but unused
zarr/_storage/v3.py:19:5: F401 `zarr._storage.store._rename_from_keys` imported but unused
zarr/_storage/v3.py:21:5: F401 `zarr._storage.store._rmdir_from_keys` imported but unused
zarr/_storage/v3.py:23:5: F401 `zarr._storage.store._path_to_prefix` imported but unused
zarr/_storage/v3.py:26:5: F401 `zarr._storage.store.array_meta_key` imported but unused
zarr/_storage/v3.py:27:5: F401 `zarr._storage.store.attrs_key` imported but unused
zarr/_storage/v3.py:29:5: F401 `zarr._storage.store.group_meta_key` imported but unused
zarr/hierarchy.py:331:24: E713 Test for membership should be `not in`
zarr/storage.py:73:5: F401 `zarr._storage.store._rename_metadata_v3` imported but unused
zarr/util.py:227:20: E741 Ambiguous variable name: `l`
Found 11 error(s).
9 potentially fixable with the --fix option.

codespell................................................................Failed
- hook id: codespell
- exit code: 65

WARNING: Cannot decode file using encoding "utf-8": fixture/8/0/32
WARNING: Trying next encoding "iso-8859-1"
WARNING: Cannot decode file using encoding "utf-8": fixture/8/0/11
WARNING: Trying next encoding "iso-8859-1"
WARNING: Cannot decode file using encoding "utf-8": fixture/8/0/23
WARNING: Trying next encoding "iso-8859-1"
WARNING: Cannot decode file using encoding "utf-8": fixture/8/0/28
WARNING: Trying next encoding "iso-8859-1"
WARNING: Cannot decode file using encoding "utf-8": fixture/0/0/4
WARNING: Trying next encoding "iso-8859-1"
WARNING: Cannot decode file using encoding "utf-8": fixture/8/0/19
WARNING: Trying next encoding "iso-8859-1"
zarr/tests/test_storage_v3.py:167: zar ==> czar
WARNING: Cannot decode file using encoding "utf-8": fixture/0/0/9
WARNING: Trying next encoding "iso-8859-1"

check yaml...............................................................Passed
mypy.....................................................................Failed
- hook id: mypy
- exit code: 1

zarr/_storage/store.py:308: error: List item 0 has incompatible type "None"; expected "Union[bytes, memoryview, bytearray]"  [list-item]
zarr/hierarchy.py:150: note: By default the bodies of untyped functions are not checked, consider using --check-untyped-defs  [annotation-unchecked]
zarr/hierarchy.py:158: note: By default the bodies of untyped functions are not checked, consider using --check-untyped-defs  [annotation-unchecked]
Found 1 error in 1 file (checked 40 source files)

@d-v-b
Copy link
Contributor Author

d-v-b commented Jul 12, 2023

@rabernat any thoughts on how to proceed here? Because of the pre-commit-ci bot, there's no way to cleanly separate the styling config changes from the styling itself in git history if we squash the commits in this PR. We could just not squash the commits, and I then exempt the CI bot's commit from git blame?

@d-v-b d-v-b mentioned this pull request Jul 12, 2023
@Saransh-cpp
Copy link
Contributor

Saransh-cpp commented Jul 12, 2023

#1460 (comment)

and, you can use ruff --fix to eliminate the need for using black, plus ruff --fix should be a lot faster than black 🙂

Copy link
Contributor

@Saransh-cpp Saransh-cpp left a comment

Choose a reason for hiding this comment

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

Also, you don't actually need a separate PR to preserve git blame. You could do something like -

  • first commit - adding the new pre-commit, new config, etc.
  • second commit - the changes introduced by the new pre-commit (let the bot commit in the PR or fix them manually by pre-commit run --all-files)
  • third commit - update .git-blame-ignore-revs with the commit hash of the second commit (and probably a comment explaining why the commit is ignored)

@d-v-b
Copy link
Contributor Author

d-v-b commented Jul 12, 2023

thanks for the pointers @Saransh-cpp! Do you have any idea why the bot is running pre-commit successfully, while my local runs produce a lot of errors?

@Saransh-cpp
Copy link
Contributor

Saransh-cpp commented Jul 12, 2023

The bot does show a few errors too, here - https://results.pre-commit.ci/run/github/48049137/1689170255.FwDDg2OQSPy25V6evetUAQ. The bot just fixes everything that it can fix and then leaves the things that have to be manually fixed. If there are things that it cannot fix, it errors out, and the logs are available in the GH Actions section of PRs.

Regarding #1460 (comment): Linting is also a part of the checks. If you scroll down in the GH Actions or the checks section of this PR, you'll find a pre-commit.ci check. Having the bot is a personal choice, some projects have it, and some don't, completely depends on the maintainers. I personally like it because it fixes PRs, runs the pre-commit check using pre-commit.ci (which is faster than running it on GH Actions), and periodically updates the versions of packages in pre-commit-config.yaml.

@d-v-b
Copy link
Contributor Author

d-v-b commented Jul 12, 2023

but this is confusing, (and maybe i just don't understand pre-commit well enough), because I thought the entire point of pre-commit hooks were that they block you from committing if they fail. So it's not obvious why the bot is committing against my branch when the pre-commit hooks are failing.

@Saransh-cpp
Copy link
Contributor

pre-commit will block you from committing locally (if you have installed it using pre-commit install in the repository), but the bot fixes the commits if someone pushes without installing the pre-commit hooks locally. Just like sometimes people push without testing their changes locally and GH Actions runs the tests for them. But again, pre-commit and the bot are personal preferences, all your points are valid, I know a lot of projects that don't use the bot because of the reasons specified by you.

@d-v-b
Copy link
Contributor Author

d-v-b commented Jul 12, 2023

the bot and I are not off to a good start, but maybe i will change my mind about it. In the meantime, I will try to work around it. thanks for your help so far!

@d-v-b d-v-b force-pushed the ruff_black_prelude branch 2 times, most recently from 95fa611 to 9c8137a Compare July 12, 2023 18:21
@d-v-b
Copy link
Contributor Author

d-v-b commented Jul 12, 2023

@Saransh-cpp I'm trying to avoid triggering this bot. Can you explain what I did wrong in my commit message?

commit 499f45ea8149eacffa717b63b7afc4384f30b18c (HEAD -> ruff_black_prelude, origin/ruff_black_prelude)
Author: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Date:   Wed Jul 12 18:21:40 2023 +0000

    style: pre-commit fixes

commit 9c8137a2cbb7c820ea595a457c7fd3257cda894b
Author: Davis Vann Bennett <davis.v.bennett@gmail.com>
Date:   Wed Jul 12 09:54:21 2023 -0400

    style: add ruff and black to pre-commit
    
    [pre-commit.ci skip]

@d-v-b
Copy link
Contributor Author

d-v-b commented Jul 12, 2023

I'm locking this branch so that the bot cannot make any more changes.

@d-v-b
Copy link
Contributor Author

d-v-b commented Jul 13, 2023

@rabernat I think this is ready. sorry for all the noise!

it looks like the repo is configured to only allow PRs via the squash and merge strategy, which will obviate the addition to .git-blame-ignore-revs. Could we do a merge commit for just this PR? Alternatively I can fix the git blame stuff in a subsequent PR.

@github-actions github-actions bot removed the needs release notes Automatically applied to PRs which haven't added release notes label Jul 13, 2023
@rabernat
Copy link
Contributor

Could we do a merge commit for just this PR?

I am absolutely fine with that. However, I'd like to check with @joshmoore before changing the repo settings.

Copy link
Contributor

@rabernat rabernat left a comment

Choose a reason for hiding this comment

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

Overall this looks good to me. It's hard to actually "review" a PR that touches nearly every file in the code base. My impression is that the pre-commit config looks right and the CI is working. The formatting changes all seem reasonable.

it would be great if someone with deeper git knowledge (e.g. @jakirkham) to weigh in on what this will do to our commit log. I don't foresee any problems, but I could be missing something.

Thanks so much @d-v-b for taking on this important chore!

@joshmoore
Copy link
Member

Here are my thoughts:

  • use of .git-blame-ignore-revs definitely helps but isn't a total panacea
  • as I mentioned to @d-v-b elsewhere (perhaps by voice but perhaps on one of his other PRs), my primary concern with this is the impact on outstanding PRs. That's the primary trade-off in my opinion that needs to be weighed.

@rabernat
Copy link
Contributor

rabernat commented Jul 13, 2023

  • my primary concern with this is the impact on outstanding PRs

Are there any specific PRs you have in mind? My sense is that there are not a lot of active PRs right now, which might make it a good time to do this change. It will never be trivial, but we have to rip the bandaid somehow.

@joshmoore
Copy link
Member

Are there any specific PRs you have in mind?

Not particularly, no. But I also haven't reviewed in a while. If you guys want to run with this, I'd ask you to take responsibility for one of:

  • closing stale PRs with an appropriate comment
  • communicating with the authors and seeing if they want to fix the conflicts
  • fixing the conflicts (e.g. by ruff'ing each of the PRs??)

cc: @jakirkham

@rabernat
Copy link
Contributor

@d-v-b - I merged #1462 before this, which has now introduced conflicts. If you can fix those, we can merge this today.

@d-v-b
Copy link
Contributor Author

d-v-b commented Jul 17, 2023

@rabernat conflicts are resolved.

@rabernat
Copy link
Contributor

rabernat commented Jul 18, 2023

For some reason codedov status has not been submitted. It would be great to have that go green before merging. Does anyone know what's going on? It looks like codecov has not received a payload for d27a6aa.

https://app.codecov.io/gh/zarr-developers/zarr-python/pull/1459

Edit: seeing this in the workflow logs

[2023-07-17T13:28:49.416Z] ['info'] Pinging Codecov: https://codecov.io/upload/v4?package=github-action-3.1.4-uploader-0.6.1&token=*******&branch=ruff_black_prelude&build=5576131092&build_url=https%3A%2F%2Fgithub.com%2Fzarr-developers%2Fzarr-python%2Factions%2Fruns%2F5576131092&commit=d27a6aa6e7b561af266c3b15d0478ac9caa6f2bc&job=Linux+Testing&pr=1459&service=github-actions&slug=zarr-developers%2Fzarr-python&name=&tag=&flags=&parent=
[2023-07-17T13:28:49.416Z] ['verbose'] Passed token was 0 characters long
[2023-07-17T13:28:49.417Z] ['verbose'] https://codecov.io/upload/v4?package=github-action-3.1.4-uploader-0.6.1&branch=ruff_black_prelude&build=5576131092&build_url=https%3A%2F%2Fgithub.com%2Fzarr-developers%2Fzarr-python%2Factions%2Fruns%2F5576131092&commit=d27a6aa6e7b561af266c3b15d0478ac9caa6f2bc&job=Linux+Testing&pr=1459&service=github-actions&slug=zarr-developers%2Fzarr-python&name=&tag=&flags=&parent=
        Content-Type: 'text/plain'
        Content-Encoding: 'gzip'
        X-Reduced-Redundancy: 'false'
[2023-07-17T13:28:49.711Z] ['error'] There was an error running the uploader: Error uploading to [https://codecov.io:](https://codecov.io/) Error: There was an error fetching the storage URL during POST: 404 - {'detail': ErrorDetail(string='Unable to locate build via Github Actions API. Please upload with the Codecov repository upload token to resolve issue.', code='not_found')}
[2023-07-17T13:28:49.711Z] ['verbose'] The error stack is: Error: Error uploading to [https://codecov.io:](https://codecov.io/) Error: There was an error fetching the storage URL during POST: 404 - {'detail': ErrorDetail(string='Unable to locate build via Github Actions API. Please upload with the Codecov repository upload token to resolve issue.', code='not_found')}

@rabernat rabernat merged commit 9043fb7 into zarr-developers:main Jul 18, 2023
21 checks passed
rabernat added a commit that referenced this pull request Jul 18, 2023
@d-v-b
Copy link
Contributor Author

d-v-b commented Jul 18, 2023

@joshmoore

Not particularly, no. But I also haven't reviewed in a while. If you guys want to run with this, I'd ask you to take responsibility for one of:

* closing stale PRs with an appropriate comment

* communicating with the authors and seeing if they want to fix the conflicts

* fixing the conflicts (e.g. by ruff'ing each of the PRs??)

Maybe I don't understand the issue here -- won't authors of active PRs be prompted to pull in the latest version of main, which will include the .pre-commit config, which they can then use on their branches?

@joshmoore
Copy link
Member

I've spent a good deal of time (previously) going through PRs and trying to keep them up-to-date. I don't necessarily expect you guys to do that, but I do think communicating what's going on would be a kind thing to do for these other contributors. Not everyone will be using pre-commit locally and if the automated check is disabled there won't be any indication of this new requirement.

@d-v-b
Copy link
Contributor Author

d-v-b commented Jul 18, 2023

I'm happy to go through and update extant PRs as needed.

joshmoore added a commit that referenced this pull request Jul 19, 2023
Without squashing to simplify the history management.
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

5 participants