-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Keeping up with new rules #2179
Comments
(Would love more input on this -- any reader, feel free to chime in. (The second thing we could probably do.)) |
It's something that I have also been dealing with at work:
For the first point , I think when categorization (#1774) is implemented, it would make sense to create a "recommended" ruleset gathering consensual categories (like "correctness", "style" , "perf" ...). The second point would definitely make the update process easier and faster. |
The other thing that would help here, possibly, or at least make it feel less overwhelming, is slowing down to a weekly release cadence. |
That would also help regarding #2136 ! |
Yeah. It would also mean I could keep a proper changelog, rather than auto-generating from PRs. (Right now, it'd take too much time to maintain a changelog with the current release cadence.) |
I like this idea, it can be useful outside of upgrading as well. |
We could imagine a strict mode, where all rules have to be explicitly selected or ignored. |
Commands that show rules (disabled, enabled, all) would be great! My 2 cents regarding naming and flags
Personally I feel the Regarding naming:
Then adding flags (like FYI: my workflowTo have an overview over what linters/rules I want to enable and which one's I explicitly disabled (because of the extremely high development speed 😀 👍), my workflow is the following:
This way I will always be alerted about new linters and I have to explicitly disable them. Preferably of course I only disable rules, not a whole linter. |
The way I tend to work in those cases ( I do the same with ESLint and its many plugins). Is that I use presets that enable everything. Then disable what I don't like or doesn't fit my/our coding standards, with comments explaining why. Save that in a preset. Disable extra-per-project rules if needed in per-project configurations that extend my base preset. For projects that need stability, I simply pin the linting/formatting dependencies. So far with Ruff this means:
|
Supposing that @rassie 's suggestion of a rules-listing command was implemented as Further supposing that each rule were somehow tagged with the first ruff version it appears in,
This would also enable a config setting that separates the workflow for getting the latest ruff code from the workflow for getting the latest ruff rules (that match my wildcard selections). For example last week my project was on 0.0.254. This week I upgraded to 0.0.259, because I wanted #3583 (colours in my Windows terminal) IIRC this didn't cause my project to fail linting, because there were no new failing rules in the categories I have selected. Indeed, many categories are already stable and will only rarely add new rules. But supposing I want to select "PL", and I haven't previously used PyLint on that code base, then updating ruff is frequently going to find new violations, some of which will be opinionated rules asking for non-trivial code refactor. Aside from the current rate of change this is no more of an issue for ruff than for (say) mypy. But I shouldn't have to refactor my code, or ideally even need to ignore a bunch of new rules, just to fix terminal colours. Linters often do it, which is why linters often get pinned to exact versions and not updated with everything else: because it amounts to conflating bugfixes with breaking changes. This may be a niche use case, of course, since quite reasonably you can say, "don't select "PL" yet if you're not already using PyLint: wait until PL is more complete and in the mean time list all the PL rules you want individually". Still, if it is useful to select unstable categories but get stable behaviour, without your ruff config being massive, then it could look like any of the following:
All of this assumes that ruff has a nice linear versioning. If in future ruff supported parallel major versions, and backports rules from ruff 2.* to the still-in-maintenance ruff 1.*, then the question of what version a rule first appeared in becomes a bit more complicated than just naming a single version. Still, within the context of each release branch it might be a single version. |
" |
(I'm going to close just in the interest of trying to keep the Issues tab actionable. We could always continue this as a Discussion if folks have other ideas or suggestions.) |
I would like a way to be notified when new categories of rules are added. Since |
i want a rule for unbounded queues. it kills me every damn time. |
With the velocity of ruff's development and the influx of new rules, it's getting harder to keep up. Are there any plans to help with rules discoverability? If not, I have two suggestions in my mind:
Sorry if I missed an existing issue about this, hope you like the suggestion.
The text was updated successfully, but these errors were encountered: