-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
ARROW-11180: [Developer] cmake-format pre-commit hook doesn't run #9045
Conversation
Thanks for opening a pull request! Could you open an issue for this pull request on JIRA? Then could you also rename pull request title in the following format?
See also: |
.pre-commit-config.yaml
Outdated
entry: bash -c "pip install cmake-format && python run-cmake-format.py --check" | ||
entry: echo | ||
files: ^(.*/CMakeLists.txt|.*.cmake)$ | ||
entry: cmake-format --in-place --autosort=false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do you use raw cmake-format
instead of our run-cmake-format.py
wrapper?
We have configuration in the wrapper.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @kou
It does the same thing. If you do it this way, then pre-commit
will figure out which files to run it on, and it'll be much, much faster:
$ time pre-commit run cmake-format --all-files
[WARNING] Unexpected key(s) present on git://github.com/pre-commit/pre-commit-hooks: sha
CMake Format.............................................................Passed
real 0m4.472s
user 0m18.011s
sys 0m0.259s
$ time python run-cmake-format.py
WARNING config_util.py:307: The following configuration options were ignored:
max_subargs_per_line
real 0m10.620s
user 0m10.594s
sys 0m0.017s
As far as I can tell, then only configuration in the wrapper is --in-place --autosort=false
- have I missed anything else?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, like this, if you enable pre-commit (pre-commit install
) then this'll run only on files you've staged, rather than on the wholecodebase each time (as it would if using run-cmake-format.py
). You can still choose to run it on the whole codebase though, with --all-files
(as in the example i posted above)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I couldn't reproduce the difference on my environment:
$ time pre-commit run cmake-format --all-files
[WARNING] Unexpected key(s) present on git://github.com/pre-commit/pre-commit-hooks: sha
CMake Format.............................................................Passed
real 0m3.476s
user 0m13.000s
sys 0m0.297s
$ time python3 run-cmake-format.py
real 0m1.358s
user 0m1.308s
sys 0m0.046s
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤔 not sure why that would be, but point taken. Though there would still be a difference if you run it as a git commit hook (i.e. if you've done pre-commit install
in your environment) because like this it'll only run on staged files, while the Python script runs on all of them each time, so this'll give faster feedback to devs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems that pre-commit
runs cmake-format
for each target file.
But run-cmake-format.py
runs one cmake-format
for all target files.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't want to reformat imported CMake files: https://github.com/apache/arrow/blob/master/run-cmake-format.py#L28-L29
( @xhochy Do you still want to avoid reformatting imported CMake files? The comment was added by you at 79c93c7. )
Could you use run-cmake-format.py
to keep the configuration for it in one place?
BTW, we can't maintain the target list by current allow list style. The patterns
is out of date. It still has renamed files. Can we change the target list to deny list style? Here is a list of imported CMake files:
cpp/cmake_modules/FindNumPy.cmake
cpp/cmake_modules/FindPythonLibsNew.cmake
cpp/cmake_modules/UseCython.cmake
(Oh... This is already reformatted...)
If run-cmake-format.py
accepts a target file like run-cmake-format.py cpp/CMakeLists.txt
and it processes only the given file, can we remove the performance difference between run-cmake-format.py
and cmake-format
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sure, will get back to this by the end of the will and will open a jira ticket as instructed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you could use pass_filenames: false
in pre-commit so that it'll just run python run-cmake-format.py
, like this configuration will all be there
It seems that pre-commit runs cmake-format for each target file.
I don't think so, it should just run cmake-format file1 file2 ... filen
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@xhochy Do you still want to avoid reformatting imported CMake files?
Yes, this helps with diffing against their upstream. We did do changes to them for our use case and this makes updating them simpler.
cb28835
to
c56dc12
Compare
.pre-commit-config.yaml
Outdated
entry: cmake-format --in-place --autosort=false | ||
files: CMakeLists\.txt$|^cpp/cmake_modules/ | ||
additional_dependencies: | ||
- cmake_format==0.6.13 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do you specify 0.6.13
?
We're using 0.5.2 as I said at #9045 (comment) .
Anyway, we can't merge this until we fix the following issues:
- ARROW-11180: [Developer] cmake-format pre-commit hook doesn't run #9045 (comment)
- https://github.com/apache/arrow/pull/9045/checks?check_run_id=1629598956
Could you fix them?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sorry, I glossed over that, fixed now
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Anyway, we can't merge this until we fix the following issues:
* [#9045 (comment)](https://github.com/apache/arrow/pull/9045#issuecomment-752475426) * https://github.com/apache/arrow/pull/9045/checks?check_run_id=1629598956
Could you fix them?
Thanks for fixing the latter.
Could you also fix the former?
.pre-commit-config.yaml
Outdated
entry: bash -c "pip install cmake-format && python run-cmake-format.py --check" | ||
entry: echo | ||
files: ^(.*/CMakeLists.txt|.*.cmake)$ | ||
entry: cmake-format --in-place --autosort=false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I couldn't reproduce the difference on my environment:
$ time pre-commit run cmake-format --all-files
[WARNING] Unexpected key(s) present on git://github.com/pre-commit/pre-commit-hooks: sha
CMake Format.............................................................Passed
real 0m3.476s
user 0m13.000s
sys 0m0.297s
$ time python3 run-cmake-format.py
real 0m1.358s
user 0m1.308s
sys 0m0.046s
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you check my comments?
Could you also revert .cmake
changes in the exclude list?
507d580
to
63c9814
Compare
bee4016
to
9e647f1
Compare
d4608a9
to
356c300
Compare
ee35ba7
to
f79b8c5
Compare
closing, but feel free to let me know if you're still interested in this and I'll pick it back up (though it doesn't look like this repo is making a big use of pre-commit anyway) |
Sorry. I didn't notice re-review request. |
@MarcoGorelli I found some problems:
I've fixed them and rebased on the current master. Could you check this? If it's OK to you, I'll merge this. |
Thanks for updating - looks good, thanks! |
Thanks for confirming this. |
Previously, cmake format wasn't running (likely because there were two `entry` keys, so the command getting overridden) - furthermore, it was unnecessarily slow as it didn't take advantage of pre-commit's own machinery Closes apache#9045 from MarcoGorelli/cmakelint Lead-authored-by: Marco Gorelli <[email protected]> Co-authored-by: Sutou Kouhei <[email protected]> Signed-off-by: Sutou Kouhei <[email protected]>
Previously, cmake format wasn't running (likely because there were two `entry` keys, so the command getting overridden) - furthermore, it was unnecessarily slow as it didn't take advantage of pre-commit's own machinery Closes apache#9045 from MarcoGorelli/cmakelint Lead-authored-by: Marco Gorelli <[email protected]> Co-authored-by: Sutou Kouhei <[email protected]> Signed-off-by: Sutou Kouhei <[email protected]>
Previously, cmake format wasn't running (likely because there were two `entry` keys, so the command getting overridden) - furthermore, it was unnecessarily slow as it didn't take advantage of pre-commit's own machinery Closes apache#9045 from MarcoGorelli/cmakelint Lead-authored-by: Marco Gorelli <[email protected]> Co-authored-by: Sutou Kouhei <[email protected]> Signed-off-by: Sutou Kouhei <[email protected]>
Previously, cmake format wasn't running (likely because there were two
entry
keys, so the command getting overridden) - furthermore, it was unnecessarily slow as it didn't take advantage of pre-commit's own machinery