hatch fmt should have the same defaults as ruff

[pfmoore]

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 the print 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 in ruff (projects can still enable and disable extra rules in their config, of course).

[warsaw]

When I was playing with hatch fmt, it's defaults did actually help me find some issues that my own ruff settings weren't finding. I also found a weird problem which I reported in #1459 (currently closed). I agree with the sentiment here too; there should be a way to bypass hatch's defaults and just use ruff+users settings, if only to aid in debugging.

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 😄

[pfmoore]

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

Very much agreed. This is really at the root of my request here, having to work out why hatch (which claims to run ruff) gives different results from bare ruff is extra confusing. Also, it's frustrating to have to configure two different sets of preferences, in two different locations, just to get the two tools to give the same results. Particularly if you want to set your personal style rules as global preferences (I'm not even sure hatch has a means to set global preferences for this).

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 🙂)

[johnpyp]

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

[dhdaines]

It also seems like hatch's default for line-length is way too long and thus gratuitously incompatible with what we thought was the standard set by Black...

So many, many, many projects still use Black, and went through a lot of trouble to get to the point where their coding style was at last totally standardized and set in place. Not very keen on changing it again.

[dhdaines]

Note that ruff is specifically designed to be compatible with Black: https://docs.astral.sh/ruff/faq/

At a minimum this should be noted in hatch documentation that you should add this to not break continuity with previously Black-formatted code:

[tool.ruff]
line-length = 88

[jamesdow21]

Easiest way to use the actual tool defaults instead of Hatch defaults is to add this to pyproject.toml/hatch.toml (link to docs)

[tool.hatch.envs.hatch-static-analysis]
config-path = "none"

(edit: I haven't actually tested this, just copying from the docs)

---

To add some other references to the docs (without weighing in on what the defaults should be or if Hatch should even be overriding the defaults)

• Overall documentation for static analysis (i.e. hatch fmt command)
• Default settings
• How-To section on customizing static analysis behavior

[jamesdow21]

A potential compromise option could be to add a Hatch configuration option with a boolean flag of whether the static analysis should use tool defaults or Hatch defaults