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

Add ruff to local tests and CI #10116

Merged
merged 4 commits into from
May 30, 2023
Merged

Add ruff to local tests and CI #10116

merged 4 commits into from
May 30, 2023

Conversation

jlapeyre
Copy link
Contributor

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.

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.
@jlapeyre jlapeyre requested a review from a team as a code owner May 16, 2023 03:17
@qiskit-bot
Copy link
Collaborator

One or more of the the following people are requested to review this:

  • @Qiskit/terra-core

@coveralls
Copy link

coveralls commented May 16, 2023

Pull Request Test Coverage Report for Build 5126433937

  • 0 of 0 changed or added relevant lines in 0 files are covered.
  • 315 unchanged lines in 32 files lost coverage.
  • Overall coverage increased (+0.04%) to 85.944%

Files with Coverage Reduction New Missed Lines %
qiskit/transpiler/passes/routing/commuting_2q_gate_routing/commuting_2q_block.py 1 95.65%
qiskit/transpiler/passes/routing/commuting_2q_gate_routing/commuting_2q_gate_router.py 1 99.07%
qiskit/transpiler/passes/synthesis/unitary_synthesis.py 1 90.27%
qiskit/transpiler/passmanager_config.py 1 97.26%
qiskit/transpiler/synthesis/aqc/cnot_unit_objective.py 1 99.26%
qiskit/circuit/add_control.py 2 96.3%
qiskit/dagcircuit/collect_blocks.py 2 98.6%
qiskit/pulse/library/symbolic_pulses.py 2 95.01%
crates/qasm2/src/lex.rs 3 91.9%
qiskit/transpiler/passes/layout/disjoint_utils.py 3 97.48%
Totals Coverage Status
Change from base Build 4982201939: 0.04%
Covered Lines: 71234
Relevant Lines: 82884

💛 - Coveralls

mtreinish
mtreinish previously approved these changes May 18, 2023
Copy link
Member

@mtreinish mtreinish left a 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
Copy link
Member

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.

Copy link
Collaborator

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 formatters
  • tox -e fix, run all formatters & fixers
  • tox -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.

Copy link
Contributor Author

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
Comment on lines 449 to 453
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.
Copy link
Member

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.

Copy link
Contributor Author

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
Copy link
Member

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.

Copy link
Contributor Author

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.

@mtreinish mtreinish added type: qa Issues and PRs that relate to testing and code quality Changelog: None Do not include in changelog labels May 18, 2023
Eric-Arellano
Eric-Arellano previously approved these changes May 18, 2023
Copy link
Collaborator

@Eric-Arellano Eric-Arellano left a 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
Copy link
Collaborator

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 formatters
  • tox -e fix, run all formatters & fixers
  • tox -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.

@jlapeyre
Copy link
Contributor Author

Ruff does have some auto fix rules

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.

@jlapeyre jlapeyre dismissed stale reviews from Eric-Arellano and mtreinish via 60024eb May 18, 2023 18:40
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`
Copy link
Member

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.

Copy link
Collaborator

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.

Copy link
Contributor Author

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?

Copy link
Collaborator

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.

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 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.

Copy link
Contributor Author

@jlapeyre jlapeyre May 19, 2023

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.

Comment on lines +451 to +452
`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.
Copy link
Collaborator

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.

@jlapeyre
Copy link
Contributor Author

jlapeyre commented May 30, 2023

  • I simplified the discussion 963958e (#10116) of running black and ruff in CONTRIBUTING. I think a discussion of requirements-dev.txt would be a great idea, but that it would be a distraction in this PR.
  • External comment on reliability of ruff autofix.
  • This is the only discussion of organizing addition of rules and default rules that I find. The bottom line seems the be that they are just adding stuff at 100 mph and releasing a lot.
  • At present running ruff remains hardcoded with no options into the existing tox test target. I also added a Makefile target. But I did not document it, again because whether and how to do that belongs in other issues and PRs. In general, I'm trying to dodge the question of how much API to offer to developers and TMTOWTDI.

Eric-Arellano
Eric-Arellano previously approved these changes May 30, 2023
Copy link
Collaborator

@Eric-Arellano Eric-Arellano left a comment

Choose a reason for hiding this comment

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

Thanks!

Partially verified

This commit was created on github.com and signed with GitHub’s verified signature. The key has expired.
We cannot verify signatures from co-authors, and some of the co-authors attributed to this commit require their commits to be signed.
Co-authored-by: Eric Arellano <14852634+Eric-Arellano@users.noreply.github.com>
Copy link
Member

@mtreinish mtreinish left a 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

@mtreinish mtreinish added this pull request to the merge queue May 30, 2023
Merged via the queue into Qiskit:main with commit 901e3b8 May 30, 2023
zanieb pushed a commit to astral-sh/ruff that referenced this pull request Jul 21, 2024

Verified

This commit was created on github.com and signed with GitHub’s verified signature.
<!--
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Changelog: None Do not include in changelog type: qa Issues and PRs that relate to testing and code quality
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants