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

[TVMScript] Optionally use ruff format instead of black #16876

Merged
merged 2 commits into from
Apr 17, 2024

Conversation

Lunderberg
Copy link
Contributor

The ruff format tool is significantly faster than the black formatter. For some particularly long TVMScript modules, using it can reduce the time required to show a formatted module from ~5 minutes to ~1 minute. This commit updates the .show() function to apply the optionally formatting using ruff format if available, falling back to black otherwise.

The `ruff format` tool is significantly faster than the `black`
formatter.  For some particularly long TVMScript modules, using it can
reduce the time required to show a formatted module from ~5 minutes to
~1 minute.  This commit updates the `.show()` function to apply the
optionally formatting using `ruff format` if available, falling back
to `black` otherwise.
Copy link
Contributor

@quic-sanirudh quic-sanirudh left a comment

Choose a reason for hiding this comment

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

This a great addition, thanks a lot. Just had one minor doubt about whether constraining to specific version of ruff is needed, but otherwise this will be really useful.

def formatter(code_str):
with warnings.catch_warnings():
warnings.simplefilter("once", UserWarning)
ruff_install_cmd = sys.executable + " -m pip install ruff"
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we restrict to a specific version of ruff similar to a specific black version we've specified below?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm uncertain, but would lean instead toward removing the specific version of black, if we want consistency. Specifying a specific version of black is useful, since then it can be matched to the CI's version, in case a developer also uses black either for format-on-save or as a pre-commit hook. However, the version number in the warning has become out of sync with the CI's version (warning message was added in November 2022, but the CI was bumped from 22.3.0 to 22.12.0 in March 2023).

Since there isn't really a good way to keep them in sync (nor any ruff version in the CI with which to be in sync), I'd lean toward removing the versions from the warning message altogether.

Copy link
Contributor

Choose a reason for hiding this comment

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

Right yeah, that makes more sense. It is very hard to keep them in sync. Perhaps after we remove the version info from the warning message, we can just add a line saying something like "For version compatibility with CI, please check docker/Dockerfile.ci_lint" if the version info has to be specified.

Thanks for the response.

@quic-sanirudh quic-sanirudh merged commit d030ce2 into apache:main Apr 17, 2024
21 checks passed
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.

2 participants