-
-
Notifications
You must be signed in to change notification settings - Fork 270
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
hatch fmt should have the same defaults as ruff #1461
Comments
When I was playing with One of the more general problems (not hatch's to solve) is that with the huge plethora of linting and formatting settings, especially that ruff supports, it's really difficult to know which ones you want to enable. Maybe we need to train an LLM just for linting+formatting help 😄 |
Very much agreed. This is really at the root of my request here, having to work out why Ultimately, what would be ideal if the linter community (is that the PyCQA?) agreed on a "core" set of checks that all linters default to as a basis. That way, users would have a stable and interoperable standard to start from. But I don't know if they are set up for that sort of community standardisation. Maybe other people are different, but my approach to linters and formatters is to find a set of rules and use them for everything. Having to set them in every project ends up being annoying boilerplate copy/paste, so my preference is to deviate as little as possible from the defaults, and mostly base my decision on trying out various tools and choosing whatever annoys me the least. I may then add rules when I find value in them, but I'll rarely switch any off (a tool that needs me to switch off its defaults fails the initial "annoys me the least" test 🙂) |
+1 on the ask for standardization ideally. In the meantime, as I'm sure there's a road of bike shedding to getting to a real standard, I also agree the default lints seem pretty heavy-handed at the moment. Taking inspiration from some of the top open source projects using ruff today seems like it could be productive. Also, I think as a general rule the lints that are focused on behavior problems in the code are much safer to enable aggressively by default, compared to stylistic or "code smell" lints that I would bias towards waiting for consensus for. Banning print for example, is one that I feel solidly falls under the second camp, whereas rules like "error on not awaiting an async function" could be universally enabled without much pushback. That said, I disagree on the same defaults as ruff, as ruff has very light defaults and seems to steer away from rules that require some amount of project awareness (like isort, for example). Hatch can actually enable these ones given its position in the stack. |
The
hatch fmt
command appears to enable a bunch of ruff checks that are (IMO) very questionable. Specifically, the T201 check disallows the use of theprint
statement, which seems extremely heavy-handed (and breaks most of my projects).IMO, hatch should by default enable exactly the same checks as ruff, for compatibility and consistency. If you're not willing to go that far, at the very least there should be a one-line configuration, that can be set both globally and per-project, which makes
hatch fmt
start from just the rules enabled inruff
(projects can still enable and disable extra rules in their config, of course).The text was updated successfully, but these errors were encountered: