Why did Hatch just prescribe a particular linter?

[oprypin]

https://twitter.com/Ofekmeister/status/1734232108413915138

I was actually perplexed by the inclusion of Ruff into Hatch in this release. I didn't think that this matches the features that people expect out of Hatch. And in particular why should Hatch dictate which rules people should use? Can't the Ruff project or any other project do that?

Which version of Ruff is used? Why is this obscured? Why should I tell Hatch to install an arbitrary version of Ruff if I can just create an env with a particular version of Ruff myself? And I'm already creating envs that have mypy, pytest and whatnot, for which I follow a common approach. It's literally less overhead to just keep using the same kind of envs rather than adding a separate mechanism. Everything already works great!

What if I want an action that formats with Ruff and something else? Surely once again it's best handled by an env that contains both.

And what if Ruff ever falls out of favor with the community? Are we really at the point where we are sure this is the last linter the world will ever need?

[oprypin]

Also just noticed the unilateral decision that 120 should be the line width. What research is that based on? If it's just a personal preference then it should be kept to a "cookiecutter"-type template that anyone can follow, rather than putting it into a well-established and unrelated project

[oprypin]

Particular things I am worried about:

There will be a perpetual disagreement whether it is a good or bad thing to use this feature.

It is also very common for me to see people who just don't want to install Hatch and do their quick contribution anyway. I don't want to encourage any setups where that is made harder - in this case it seems like this feature really does obscure the setup in that you can't just run Ruff directly anymore. (though the docs do encourage making the config explicit, at which point this is just a built-in single-purpose and single-origin cookiecutter template)

[oprypin]

I also see unstable rules from Ruff being prescribed. But the meaning of what the rules do can completely change without notice between versions. In which case the version of Ruff absolutely must be pinned.

And if that is done, then the frequency of updates that you can do will be limited by how often Hatch will make a new release? Because I presume the set of rules is part of the Hatch release?

[oprypin]

Also I think if this was made as a plugin for Hatch then that would be just amazing. Then you could more easily swap it out for any other plugin from any provider, including a forked plugin if you're so inclined

[ofek]

Hey there Oleh!

I was actually perplexed by the inclusion of Ruff into Hatch in this release. I didn't think that this matches the features that people expect out of Hatch.

Hatch is trying to be the Cargo or Go CLI equivalent for Python. A fundamental part of a user's workflow is checking static analysis and formatting which is why both of those tools have that command built-in. The next command I will be implementing is test which will be a wrapper around pytest and select plugins to provide an out-of-the-box good experience for users.

I can't express enough how important it is for me that Hatch provides a default excellent experience for users that satisfies the majority of use cases. Anything more advanced can of course be described in custom environments per usual.

And in particular why should Hatch dictate which rules people should use? Can't the Ruff project or any other project do that?

As I mentioned I want to provide a good default experience. In this case, users don't have to research which rules to select and whether or not it's good practice to disable others. When Ruff does provide that functionality then I would be interested in outsourcing to them but right now they do not have that. I am trying to be as active as I can be with them to make sure that whatever their selection of "mostly desirable rules" closely matches Hatch not just to prevent churn for users but also because I think the defaults precisely map onto best practices in modern Python.

You bring up a good point however in that there is currently no way to disable the defaults and just use the command as an interface to Ruff. I will add this; thank you!

Which version of Ruff is used? Why is this obscured?

I document that here.

What if I want an action that formats with Ruff and something else? Surely once again it's best handled by an env that contains both.

As you mentioned you can do whatever you want since you are a very experienced developer and know exactly what to do! The issue is that many others are not at your level and won't be for years. I want them to have an easier time like Cargo is helping with.

And what if Ruff ever falls out of favor with the community? Are we really at the point where we are sure this is the last linter the world will ever need?

I would bet my life on the fact that this will not occur in the next decade.

Also just noticed the unilateral decision that 120 should be the line width. What research is that based on?

It's a common line length for the modern era where we are not working in a restrictively slim terminal, example comment here and here.

I thought about going with 100 which is what Rust's formatter defaults to and just ended up at the wider of the two standard wide options. I would be open to changing to 100 since the release happened just yesterday but I would like to hear your thoughts more on that topic as it seems the trend is moving higher.

It is also very common for me to see people who just don't want to install Hatch and do their quick contribution anyway. I don't want to encourage any setups where that is made harder - in this case it seems like this feature really does obscure the setup in that you can't just run Ruff directly anymore.

Can you please give an example of your concern here? I don't quite understand.

I also see unstable rules from Ruff being prescribed.

They are listed for completeness but are only enabled when running in the standard preview mode.

the frequency of updates that you can do will be limited by how often Hatch will make a new release? Because I presume the set of rules is part of the Hatch release?

This is a valid concern which can be abated by allowing projects to pin the version and Hatch will have knowledge of the defaults for every version. I thought about doing this but if I block on every feature I think of then there would never be new releases 😉

The user can then select the version at will.

Also I think if this was made as a plugin for Hatch then that would be just amazing. Then you could more easily swap it out for any other plugin from any provider, including a forked plugin if you're so inclined

Interesting idea, I will consider this!

[oprypin]

Thanks for the response :) partly answered but I'll comment further.

Hatch is trying to be the Cargo or Go CLI equivalent for Python

Hmm I wasn't aware that this is the direction. And worth pointing out that (IIUC) those are provided by the authors of the language itself

I can't express enough how important it is for me that Hatch provides a default excellent experience for users that satisfies the majority of use cases

I think this could still be satisfied by having a fmt environment pre-populated by hatch new. Then fewer features to be aware of, which I think is beginner-friendly in a different way?

The next command I will be implementing is test which will be a wrapper around pytest and select plugins

Also worrisome to me in the same manner, and also I think best handled by just pre-populating an env :( or again just a plugin would be great.
And pytest isn't even beginner-friendly like unittest is, or recognizably dominant like ruff is. Fixtures are a unique and un-intuitive feature for anyone coming from anywhere else.

Which version of Ruff is used? Why is this obscured?

I document that here.

Oh I see, I was just confused by the variable name but actually it's used as a == dependency

hatch/src/hatch/env/internal/fmt.py

Line 16 in 4e25463

'dependencies': [f'ruff=={RUFF_MINIMUM_VERSION}'],

Also just noticed the unilateral decision that 120 should be the line width. What research is that based on?

I would like to hear your thoughts more on that topic as it seems the trend is moving higher.

I have no thoughts on a particular choice of line width, I just know that whatever anyone chooses is arbitrary, so it's a bit brave to basically declare the upstream choice wrong and make a particular other choice for all users.

It is also very common for me to see people who just don't want to install Hatch and do their quick contribution anyway.

Can you please give an example of your concern here? I don't quite understand.

Just imagine that some Python project uses an obscure project management tool / command runner tool (for you, imagine it being not Hatch, and for others, imagine that Hatch is something scary and obscure) and that project didn't even document their setup (because it's obvious that you should just run hatch run style:fix). But you want to download that project's code and make some quick edit to it and send out a pull request. Before sending it, you want to run tests and format the code. You don't want to figure out what setup they have and install that tool, but you do see that "ruff" and "pytest" is mentioned. So you do a quick little ruff src; ruff fmt src; pytest tests and you're good to go. I aspire to keep that ability for my projects to some extent and also wish that others would, and I feel like it's being eroded; you'll really have to download Hatch to get the same config, and also ruff is now possibly never mentioned in the project despite being used there.

This is not hypothetical, I've been in that situation myself from both sides. Most recently I was the guy who didn't document the setup- mkdocs/mkdocs#3507. Other times I was the lazy (or cautious?) guy not wanting to follow instructions that start with "just run make setup first".

[gunungpw]

From the view of a new Python user,
hatch uses ruff is a nice touch so I don't need to manually add and setting the linter/code formater
But also I think hatch needs to make the setting that hatch use, be transparent to the user (in pyproject.toml)
So, just like coverage and mypy, the ruff version and other settings will be seen in pyproject.toml and if the user want to change the default linter it will just change the configuration in pyproject.toml
In my opinion the hatch fmt default ruff is a very good and reasonable choice because it has very few dependencies (i think it just a package ruff) and fast but if the user want to use black hatch also can attach hatch fmt to black with a setting that provided in pyproject.toml

[ofek]

The version of Ruff can now be configured https://hatch.pypa.io/latest/blog/2023/12/18/hatch-v190/

In the next minor release you will be able to change the behavior of the fmt command completely.

[schlich]

Love ruff, love the plans for an opinionated approach to this package. The "ruff_defaults.toml" is a little weird, and I don't get it. It needs clearer documentation for an unfamiliar pattern and a green "this is the recommended approach" box. FWIW i run all day on select=["ALL"] and love it. It's like a little python fun "fact of the day" buddy.

pytest is pretty much boilerplate for any python project, I haven't seen unittest in the wild in years (unless you're using unittest.mock, but pytest-mock also exists for that... on that thought, maybe that should be bundled.)

The only true holdout i know of is Django, which runs tests from their django-admin command and does not run the pytest runner by default.

[ofek]

#1184

[ofek]

Next release you can do this: https://hatch.pypa.io/dev/how-to/static-analysis/behavior/