-
Notifications
You must be signed in to change notification settings - Fork 85
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
Auto formatting via pre-commit.ci
#136
Merged
Merged
Changes from 2 commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
FYI, this pinning will probably be updated by the “autoupdate” functionality of pre-commit.ci.
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.
Right, this is why I set the update frequency to
quarterly
. And according to pre-commit-ci/issues#83, there is no plan to provide a schedule-off option.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 support
quarterly
just to keep the number of PRs down -- but it does seem like we could update the pinnings before we merge this PR, since it's going to keep clang-format updated anyway. (Unless we're trying to stay pinned tov11.1.0
for some reason? I don't think the choice of version matters if it's automatically enforced.)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.
Done
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.
Do we want to keep this version in line with RAPIDS? AFAIK most cuCollections developers (at least at present) are RAPIDS devs, and having this misaligned could lead to issues if users choose to invoke clang-format via the CLI and they have a different version installed than the one specified by pre-commit. I would be fine if the answer is no, but we should be aware of the issues this discrepancy could cause.
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.
That’s my point: any issues caused by misaligned versions will be auto-fixed by CI, so it doesn’t matter what devs have locally. Moreover, you can’t really pin the version because pre-commit CI will open a PR to update it to the latest version every quarter. Personally, I am perfectly okay with keeping the pinnings updated on a quarterly basis and ignoring whatever devs have locally in favor of the pre-commit autofixes.
If we implemented our own “auto-fix” solution in gpuCI similar to pre-commit.ci, then we’d have greater control over version pinnings. However, I don’t think that is needed.
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 agree with @bdice, any version mismatch issues will be auto fixed by CI anyway. By all means, it's clearly stated in README that directly using
clang-format
on the command line is not recommended.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.
To be clear, I understood what @bdice was saying about how things would work. I'm asking for a value judgment on whether we think this is a problem. We explicitly declined to move in this direction for RAPIDS because it would prevent using the format-on-write hooks in VSCode, which can't use the pre-commit hook. I don't personally use VSCode, so I don't care about that feature, but before we commit to this approach I just wanted to make sure that everyone involved recognized the limitations since lack of VSCode integration was deemed sufficient reason not to rely on pre-commit versioning in RAPIDS. I'm happy if we just stick with pre-commit though :)
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 see your point. This could be a problem not only for VSCode but for all IDEs/editors having auto-formatting support. Technically, users can still stick with the IDE/eidtor
clang-format
hook. It's just any mismatches will be then auto-fixed by CI (orpre-commit
hook).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'm strongly in favor of trying this approach here. If it works well, I want to eventually revisit that conversation for RAPIDS or cuDF in particular. I don't expect it to be painful, and I suspect it will lead to greater productivity than our current approach of waiting for CI to fail and then identifying/fixing/committing/pushing "style fixes." The current manual approach costs us so much in CI retry time and hinders our iteration speed. Lately I've been doing a lot of work via github.dev (to make small changes, since it's vastly quicker than dealing with local branches / etc. and I can work in lots of browser tabs at once) and automatic CI fixes for style would be so awesome to add to that workflow.