Use ruff instead of flake8

[WhyNotHugo]

Configure ruff to lint code performing the same validations as the existing flake8 setup.

See: #1886

Contributor checklist

• Included tests for the changes.
• PR title is short, clear, and ready to be included in the user-facing changelog.

Maintainer checklist

• Verified one of these labels is present: backwards incompatible, feature, enhancement, deprecation, bug, dependency, docs or skip-changelog as they determine changelog listing.
• Assign the PR to an existing or new milestone for the target version (following Semantic Versioning).

[webknjaz]

Please keep the config in .ruff.toml. Mimick the shape I have in Cheroot. It is important to be able to sync configs across projects with minimal diff.

Additionally, the hook might need extra args to actually fail on violations, IIRC.

Also, are you sure this covers all flake8 rules?

[webknjaz]

Urgh.. I don't like this accessibility-unfriendly length but I suppose we can fix it later.

[WhyNotHugo]

I also dislike this. I've kept this PR in line with existing settings, we can review them as a follow-up.

I'll also switch over isort in a separate PR to keep reviews simpler.

[WhyNotHugo]

Please keep the config in .ruff.toml

Why prefer a dotfile instead of the regular pyproject.toml? The latter is the more common approach, standard in the ecosystem, and doesn't hide settings.

Mimick the shape I have in Cheroot. It is important to be able to sync configs across projects with minimal diff.

I don't know what this is or what this means.

Additionally, the hook might need extra args to actually fail on violations, IIRC.

Fixed. Completely forgot about this.

Also, are you sure this covers all flake8 rules?

Yes. The ruff docs state:

By default, Ruff enables Flake8's F rules, along with a subset of the E rules, omitting any stylistic rules that overlap with the use of a formatter, like ruff format or Black.

I added explicit configuration for the flake8-pytest rules.

[webknjaz]

Please keep the config in .ruff.toml

Why prefer a dotfile instead of the regular pyproject.toml? The latter is the more common approach, standard in the ecosystem, and doesn't hide settings.

It's unusual in my projects to dump everything into one file because it's super inconvenient. Many projects still have their own configs because it's problematic.

https://blog.jaraco.com/skeleton/#updating

Mimick the shape I have in Cheroot. It is important to be able to sync configs across projects with minimal diff.

I don't know what this is or what this means.

Imagine having tens or hundreds of projects where you need to make the same updates. If the files are small and separate, you can use diff mode in the editor or copy files right away. When bits of files diverge across the repos, making updates using diff mode isn't that difficult. But one's multiple intertwined reformatted and reordered sections appear on the same file, it's always nightmare, multiplied by the number of projects.

Having dedicated files makes it easier to find where things are and reduce the drift-related friction so much that I find it utterly unacceptable to dump everything into the pyproject.toml file. It might work if you maintain a near-zero amount of projects or never sync configs across and configure from scratch every time. However, I don't have a luxury of wasting so much time.

[webknjaz]

I think that to be equivalent to flake8, we need to enable its rule categories. I don't really trust ruff to do implicit magic with that.

[WhyNotHugo]

All other projects to which I've contributed or have access use pyproject.toml. I used those as a loose reference when making these changes. None of them reach 200 LoC.

Personally, I find diff'ing a single file quicker than diff'ing a tree of lots of tiny files.

I also dislike the idea of hiding this this kind of configuration in dotfiles, when the typical convention is to have them in a single, standard file.

I don't have time or interest in making a snowflake configuration for this project that meet your requirements. If that is a blocker, feel free to close this.

[sirosen]

I am net-neutral towards ruff, but if we don't have alignment on the config, I move to close. (Please second this by closing if you agree.)

I can conform my style to whatever a project needs, within reason, but ruff not offering plugins continues to disappoint me. I don't find the speed as impactful as many others in the community seem to.

Two thoughts which are all I'll say on the review front:

• I prefer for tooling changes to be kept as orthogonal to source tree changes when possible, so I like the way that this was done, in that piptools/ has no changes simply because the tool changed. That makes review and change tracking easier. 👍
• It's really hard to evaluate a change between linters in general, since you can't easily see what passing rules are being added or removed. Not a particular burden to this PR, just a broad issue.

[webknjaz]

@sirosen there's no reason we can't take over the PR and move the config, even if Hugo does not want to be working on this himself. Evidently, we have different experiences and what seems right to him brings a lot of inconvenience to me. But given how I'd like to align multiple projects, the config location is a blocker at the moment.

And yes, it seems difficult to me to evaluate linter replacements. I think I was adding ruff additionally w/o removing old things in my other projects. But there, I took a different approach of enabling all the rules and making exclusions, which would cover more things.

[WhyNotHugo]

If you're attempting to align multiple project, I suggest aligning to what the greater ecosystem is doing, rather than align them with a diverting approach.

Eventually it's your call.