-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Add ruff to local tests and CI #10116
Conversation
This adds linting using ruff to the relevant configuration files. Only a few rules are enabled and none of them trigger an error in the current state of the repo.
One or more of the the following people are requested to review this:
|
Pull Request Test Coverage Report for Build 5126433937
💛 - Coveralls |
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.
This LGTM, I think there are probably some other low hanging fruit rules we can add that are unlikely to be controversial or cause conflicts. But that's easy enough to do in a follow up. This starts us getting used to using the tool and we can incrementally ramp things up from here until we're ready to drop pylint. Just a couple questions inline but nothing blocking
running `tox -elint` which will run `black`, `ruff`, and `pylint` to check the | ||
local code formatting and lint. If black returns a code formatting error you can | ||
run `tox -eblack` to automatically update the code formatting to conform to the | ||
style. However, if `ruff` or `pylint` return any error you will have to fix |
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.
Ruff does have some auto fix rules which can automatically be fixed (to some degree at least) with --fix
. But, probably not worth getting into that here.
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.
No need to block this PR on this. But, I find it useful to have three top-level commands:
tox -e fmt
, run all formatterstox -e fix
, run all formatters & fixerstox -e lint
, run all formatters and fixers in check-only mode, along with pure linters
Why split fix
and fmt
? You sometimes only want to format your code without making any semantic changes. For example, some "fixers" will remove unused import. But that import might only be unused because you are still writing the code.
We've used fmt
vs fix
vs lint
in Pantsbuild (a build system) for the past year and it's worked great.
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.
And we have unused imports just for the side effects. I made a comment about fixing below. I agree you have to be a bit more careful with running fix. I think something like your three commands looks good. But maybe not for this PR.
CONTRIBUTING.md
Outdated
You can also run just `ruff`. If you have installed the development packages in | ||
your python environment via `pip install -r requirements.dev`, then `ruff` will | ||
be available. Otherwise install it with `pip install ruff`. Running the command | ||
`ruff check qiskit test tools examples setup.py` will run the same `ruff` tests | ||
that are run via `tox` as well as in 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.
I assume you put this here because ruff is fast and people might want to run it standalone. If so black fits into this category too.
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.
Exactly. Some people (myself included) like to avoid tox
when possible because it's a bit slow and complicated. Even though I run it at least once when everything is ready. And yes, adding a note about black
makes sense and I don't think complicates the PR.
@@ -11,6 +11,7 @@ black[jupyter]~=22.0 | |||
pydot | |||
astroid==2.14.2 | |||
pylint==2.16.2 | |||
ruff==0.0.267 |
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 think pinning is the right call, but I'm curious if ruff has any documentation on their stability policy. Like black makes it very clear there will be no default rule changes for a year/major version which is why we pin on ~=22.0.0
which should be stable but still get bugfixes. I'm assuming it's probably too early for ruff to have a policy like that.
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.
Hmm dunno. I can check. I did see that 0.0.266
was withdrawn. But we can always deal with that kind of thing fairly easily.
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.
Thanks!
running `tox -elint` which will run `black`, `ruff`, and `pylint` to check the | ||
local code formatting and lint. If black returns a code formatting error you can | ||
run `tox -eblack` to automatically update the code formatting to conform to the | ||
style. However, if `ruff` or `pylint` return any error you will have to fix |
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.
No need to block this PR on this. But, I find it useful to have three top-level commands:
tox -e fmt
, run all formatterstox -e fix
, run all formatters & fixerstox -e lint
, run all formatters and fixers in check-only mode, along with pure linters
Why split fix
and fmt
? You sometimes only want to format your code without making any semantic changes. For example, some "fixers" will remove unused import. But that import might only be unused because you are still writing the code.
We've used fmt
vs fix
vs lint
in Pantsbuild (a build system) for the past year and it's worked great.
I found they are not quite as fool proof as, say black. I don't recall the details. Maybe that we might want to make some exceptions. In any case, I tried to avoid complicating this first PR. |
CONTRIBUTING.md
Outdated
Because they are so fast, it is sometimes convenient to run the tools `black` and `ruff` separately | ||
rather than via `tox`. If you have installed the development packages in your python environment via | ||
`pip install -r requirements.dev`, then `ruff` and `black` will be available. Otherwise install them | ||
with `pip install ruff black`. Running the commands `ruff check qiskit test tools examples setup.py` |
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.
This is potentially problematic to suggest because of our pinning. If you run pip install black
for example it will pull in a 23.x.y
version which will behave differently than what CI will check (I think we can look at bumping it in a separate PR as it's separate), but it might be good to include the pins here although I guess it's one more place to keep in sync.
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'd recommend we remove this paragraph for the exact problem you're describing.
One option is to have multiple environments:
tox -e fmt
tox -e fix
tox -e lint
tox -e ruff
tox -e black
tox -e pylint
The downside is that tox.ini
will be more awkward, but that doesn't seem like a big deal to me. Optimize for developer experience, not how elegant a config file is that very few people touch.
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.
Fine to remove the line about pip install...
Won't tox -e ruff
be much slower than just running ruff
?
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.
Won't tox -e ruff be much slower than just running ruff?
Why? It will be annoying the first time you have to install the virtual environment. But otherwise it should be roughly the same speed.
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 looking for a good place in the contributors doc to warn users that they should install dev tools only via requirements-dev.txt
. Or at least get the correct version if they do it piecemeal (btw, Having a robust packaging system instead of talking about this would be convenient.). I notice that reno
is pinned, but there is an instruction to just pip
install it.
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 tried a ruff
target in tox.ini
. It runs in 900ms. Running ruff
directly is 23ms. And less if you run it only on the directory you are editing. The story with black
is similar... But I don't think the comments I added there are optimal. I mean giving explicit instructions for one invocation of ruff
at the cli doesn't really belong there.
`pip install -r requirements-dev.txt`, then `ruff` and `black` will be available and can be run from | ||
the command line. See [`tox.ini`](tox.ini) for how `tox` invokes 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.
Nice change. I like this.
|
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.
Thanks!
Co-authored-by: Eric Arellano <14852634+Eric-Arellano@users.noreply.github.com>
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.
LGTM, thanks for doing this
<!-- Thank you for contributing to Ruff! To help us out with reviewing, please consider the following: - Does this pull request include a summary of the change? (See below.) - Does this pull request include a descriptive title? - Does this pull request include references to any relevant issues? --> ## Summary Just updating the README to reflect that IBM has been using ruff for a year already: Qiskit/qiskit#10116.
This adds linting using
ruff
to the relevant configuration files. Only a few rules are enabled and none of them trigger an error in the current state of qiskit-terra.The immediate goal of this PR is to test integrating
ruff
into local workflows as well as CI. This is the reason why only very few rules are enabled, and none necessitated code changes.If this PR is successful, more
ruff
rules will be added in subsequent PRs.