-
Notifications
You must be signed in to change notification settings - Fork 103
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 pre-commit (before isort + flake8 to test it as a possible replacement) #490
Conversation
✅ Deploy Preview for conda-lock ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
"E501", | ||
"F401", | ||
"F403", | ||
# Disabled during migration to 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.
Many of these can be enabled and autofixed, but I felt it would be better to tackle it in a separate PR to keep a reasonable scope for this one :)
select = [ | ||
"A", # flake8-builtins | ||
# "B", # flake8-bugbear | ||
"B006", # Do not use mutable data structures for argument defaults |
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.
flake8-mutable
errors are caught by this rule. Looks to have detected something that was previously undetected, too.
Ruff is fast, and this commit only aims to take advange of that, not to add new rules.
These all felt likely to be uncontroversial choices for letting Ruff autofix some new rules.
PR got autoclosed because of a rebase mistake, woops. |
@@ -768,7 +768,7 @@ def create_lockfile_from_spec( | |||
*, | |||
conda: PathLike, | |||
spec: LockSpecification, | |||
platforms: List[str] = [], | |||
platforms: Optional[List[str]] = None, |
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.
Thinking out loud: This is probably safe as-is because this function would only be called one time per CLI invocation. But if that assumption changes, this use of a mutable default value could bite in the future.
@@ -1,19 +1,12 @@ | |||
black |
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.
If black
is installed and run with pre-commit, maybe it doesn't need to also be here? Same for mypy?
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's still useful to have in the dev environment. If you're running VS Code, then black is a requirement for "Format Document..." (although I'm not 100% sure this is still the case since they came out with the Black VS Code extension.)
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, ruff is a linter, not a type checker, so I think we want to keep mypy, at least for 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.
Also, ruff is a linter, not a type checker, so I think we want to keep mypy, at least for now.
Yes, I was more thinking about mypy being on the slow side to use in a pre-commit workflow, not about eliminating it entirely. I don't want to touch mypy for this PR in any case, one thing at a time is enough for me 😆
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's still useful to have in the dev environment. If you're running VS Code, then black is a requirement for "Format Document..." (although I'm not 100% sure this is still the case since they came out with the Black VS Code extension.)
Interesting. I'm not a VSCode user, but I assumed that would integrate with pre-commit as well. Makes sense!
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 a lot for this!
I understand mypy being slow, but I've never found flake8 to be cumbersome. Maybe I work more slowly than most people.
I know lots of people are really excited about ruff, and it is incredibly fast. On the other hand, flake8 is tried-and-true, and I like its extensibility with plugins.
How would you feel about leaving in flake8 and isort for now? In my current main project I added ruff at the end of my pre-commit list. That was a mistake because I never see it do anything. Let's do better here and put it at the top of the list, and then if I see flake8 no longer doing anything then I'll learn to trust it.
@@ -1,19 +1,12 @@ | |||
black |
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, ruff is a linter, not a type checker, so I think we want to keep mypy, at least for now.
I'm OK with whatever you all want to go with :) I noticed flake8 being slow because I'm working sometimes on an older Thinkpad. To provide my personal experience with Flake8 vs Ruff (and probably sound like a gushing fan, and I am), I've been using flake8 for about 7 years now as a valued daily tool, but have replaced it with Ruff for every project I start or revisit because I truly feel Ruff has far overtaken it in every way. It being fast is just a (really nice) bonus to me.
The combination of the two above things, more rules + autofixing, means I can do amazing things like change Ruff's I the best way to try it out is as you described, putting Ruff first but keeping flake8 and isort on board until the team feels they are not adding anything! I'll push a commit to that effect now. |
Unfortunately, isort is reversing a change made by Ruff. I really disagree with diff --git a/conda_lock/lockfile/v2prelim/models.py b/conda_lock/lockfile/v2prelim/models.py
index 2cc35c2..038a7e1 100644
--- a/conda_lock/lockfile/v2prelim/models.py
+++ b/conda_lock/lockfile/v2prelim/models.py
@@ -7,12 +7,10 @@ from conda_lock.lockfile.v1.models import (
GitMeta,
HashModel,
InputMeta,
- LockMeta,
- MetadataOption,
- TimeMeta,
)
from conda_lock.lockfile.v1.models import LockedDependency as LockedDependencyV1
from conda_lock.lockfile.v1.models import Lockfile as LockfileV1
+from conda_lock.lockfile.v1.models import LockMeta, MetadataOption, TimeMeta
from conda_lock.models import StrictModel Having isort and ruff in the pre-commit chain puts the two tools into a disagreement loop. There may be a way to config them to agree more... |
I'm sure there are better ways to do this than `# isort: skip_file` and flake8 `per-file-ignores`, but this is what I had time for today :)
I think GitHub is having some problem with the PR sync process, because I pushed a commit to this branch on my fork (GitHub correctly shows that commit was pushed), but the commit isn't showing up in this PR. There's an incident right now, maybe related. |
Ya, a few months ago there were several days of GitHub incidents where I was observing similar behavior of disappearing pushes. I'm seeing 95f64ea. @mfisher87 is that your latest? If so, let's get this merged! |
Since when is the Windows test passing? I wonder if that's thanks to the new Mamba/Micromamba releases? Also, @mfisher87, would you like to prepare a PR with a commit reverting 95f64ea? |
🤩 and in less than 30 minutes! That's a big difference from timing out in 6 hours.
Yes, looks like GitHub got caught up now :) Sounds great! You're good with using selective ignores to work around the places the tools disagree?
Sure! Just to make sure I understand, this would be preparing a PR in advance to be merged if/when contributors feel more comfortable with Ruff? |
I felt the |
Ya, it was only timing out since there was a particular test that was hanging with Mamba, #483. Hopefully I can close it now!
I didn't quite follow this. Are you talking about pre-commit? If so, I didn't set up the ignores for this repo.
Exactly. |
I was referring to the new ignores added in this PR - this and this. These are a bit hacky, but since we're going to have a reversion PR, we don't need to remember to come back and get rid of them later :) |
In conda#490, Ruff was added to try it out. Ruff could theoretically replace isort and flake8. This commit removes them and removes compatibility hacks in case we decide we do want to drop isort and flake8.
Ya, no worries, that's fine. |
Description
I was doing some development for #485 and felt that flake8 was uncomfortably slow to be running in pre-commit (same with Mypy, but one thing at a time ;) ). I've really loved using Ruff on my other projects so I thought I'd propose swapping over with a minimal PR that aims for consistency with the old ruleset and autofixing a few new rules I felt were uncontroversial based on the changes in #420.