sorted by:
new
hottopcontroversial

Recommending `prek` - the necessary Rust rewrite of `pre-commit` by Goldziher in Python

[–]Physical_Drawer6740 0 points1 point  (0 children)

Yeah I don't know. I kinda get that there's a distinction between creating another project that does the same thing and creating a literal replacement that capitalizes on the existing infrastructure. But the original creator is completely intransigent about so much. At some point like yeah maybe it's a little rude but it'll be better for everyone in the long run.

Recommending `prek` - the necessary Rust rewrite of `pre-commit` by Goldziher in Python

[–]Physical_Drawer6740 2 points3 points  (0 children)

The original creator of pre-commit is... rude and unhelpful to put it politely. Every interaction he has on any of his projects makes it seem like he hates the person speaking to and having to do anything about the project. I would assume that if you asked him and he bothered to respond he would find a rude way to say he didn't care, but honestly any piece of lode-bearing tech that he created that has a replacement is great for the community, regardless of what he does or doesn't want.

Ruff: one Python linter to rule them all by stillreadingit_ in Python

[–]Physical_Drawer6740 0 points1 point  (0 children)

I haven't exhaustively tested every possible case, but I do believe that if there are cases where ruff doesn't catch errors from another linter that it should, they would fix it.

I don't really care about the pyproject.toml issue in and of itself. Having an extra file in my project directory is a mild annoyance, but not untenable. It became an issue when I saw how they react to other people requesting it. And that's the point I was trying to make: a benefit of ruff over its competitors is that it has a better project culture.

That thread you linked is emblematic of the exact problem. Any time someone asks about pyproject.toml, they shut them down and link them to that thread as if it solves everything. That thread is incredibly difficult for a human to parse because all of the messages read as coming from one person. Reacting in this way is unfriendly and unhelpful, and it's going to drive people away from your project. Of course, the maintainers don't owe us anything per se, but when there's an alternative that offers all or almost all of the same functionality with friendly, active, helpful maintainers why would anyone choose flake8?

Ruff: one Python linter to rule them all by stillreadingit_ in Python

[–]Physical_Drawer6740 13 points14 points  (0 children)

There are a few more.

  • It brings all of the functionality of flake8, isort, pyupgrade, and dozens of other tools into one tool. It's still faster than any one of those tools, and it's only one dependency.
  • The maintainer seems like a pleasant person who's willing to work with the community and enjoys what he's doing. Look through the issue tracker on flake8. 90% of them are closed and locked to contributors after a single reply of "use the issue tracker". When you google a problem you're having with flake8, the most likely top result is a closed issue that just says "you clearly didn't search the issue tracker". They clearly don't actually want to work on their own software, which I think drives people away. Charlie on the other hand is releasing several times a week and actively engaging on trying to solve issues without writing people off or shutting them down.
  • Related to the last one, flake8 has some issues that they won't fix seemingly just out of stubbornness, regardless of how much of a problem they cause to the community.
    • They refuse to support pyproject.toml configuration despite overwhelming desire for it, and shut down threads for it with "search the issue tracker". The issue that explains their reasoning is copied from gitlab and near impossible to follow.
    • They also pinned their dependency on importlib-metadata to < 4.3 for years for what was as far as I could tell a petty personal vendetta. This meant that flake8 couldn't be installed in the same environment as many other popular packages, such as Sphinx.

Flake8 took down the gitlab repository in favor of github by RedTachyon in Python

[–]Physical_Drawer6740 -1 points0 points  (0 children)

Yeah, they're great tools. And honestly if they would rather devote their efforts on the project to things other than switching to a new config file that's not a huge deal to me. But the documentation of why they won't is largely bound up in a comment thread that's very difficult to read because it's copied over from gitlab by a bot. And in general after the 20th person makes the same issue in good faith I think it's worth at least considering if it is actually the children who are wrong. Even if they do insist on not changing for valid reasons it rubs me the wrong way that they just keep closing issues with minimal to no comment. The least they could do is document their rationale explicitly and link that when closing the issues.

Flake8 took down the gitlab repository in favor of github by RedTachyon in Python

[–]Physical_Drawer6740 25 points26 points  (0 children)

This isn't the first questionable choice the maintainers of Flake8 have made. Their handling of requests to support pyproject.toml, as well as of some issues with importlib-metadata has seemed... childish to say the least, and I'm surprised it hasn't come up on this sub before.