Comment by kstrauser | Hacker News Reader

Comment by kstrauser | Hacker News Reader

I love Ruff. It's amazing. It's blindingly fast. I dig it.

But. v0.1.0 comes with a breaking change: the old `--output` option is now named `--output-format`, and it was only deprecated 3 weeks ago in version 0.0.291 (https://github.com/astral-sh/ruff/releases/tag/v0.0.291). That's bound to break some CI pipelines, and definitely breaks the python-lsp-ruff language server plugin. If you use the latter, I have a PR at https://github.com/python-lsp/python-lsp-ruff/pull/48 that will get you running again for now.

To be super clear, the Ruff team doesn't owe it to anyone to make the command line stable. This is a little inconvenient, but that's our problem, not theirs. They've made an amazing free tool we can all use. Still, it's something you'll need to know about and deal with.

Edit: “our” as in “us end users”. I’m also just an end user of python-lsp-ruff and not associated with it. I realized on re-reading that it might sound like I’m one of its developers. Nope!

This announcement post specifically addresses this: v0.1.0 introduces a new versioning policy [0], where patch versions (v0.1.1) are guaranteed to no longer break "stable" features, while minor versions (v0.2.0) can. At some point I'd assume they plan on stabilizing it such that even minor versions don't break stable features, but as a sibling notes, using v0 as a project's major version is usually intended to communicate that you shouldn't count on things staying stable.

[0] https://astral.sh/blog/ruff-v0.1.0#ruffs-versioning-policy

Yep. Again, I’m not complaining. It broke a thing I use, so I fixed the thing.

However, it’s something that pretty much all Ruff users to know about. Some projects look at their big x.y.Z number and decide to bump y or x to say “hey, it’s been long enough, let’s call it a new version”. This isn’t one of those cases.

I can’t overstate how much I agree with the Ruff team in not being afraid to break things at this point. They have a very promising new tool, but it is very early. They are still very much learning the space and best way to produce their product.

It would be an absolute tragedy if they felt compelled to maintain backwards compatibility for philosophical reasons at this stage, if they felt it constrained the capability or usability of their product.

If they're using semver, having a major version number of zero means that any change can be breaking. Additionally, while it's not part of the semver spec, to me having the minor version be zero as well is an even bigger indicator that nothing is stable.

Sounds like they'll be using the cargo variant of semver where changing the leading digit is a breaking change with a common expectation that fewer leading digits implies "better" for varying metrics of "better" (fewer breaking changes, more production ready, etc).

Agree with this as both someone who depends on projects that introduce breaking changes, and as an author of libraries that follow this convention.

Introducing breaking changes can be a hard decision to make, especially knowing that downstream consumers might disagree and their things might break, but the version numbers let you know that it's still unstable and introduced breaking changes.

What's keeping you using `python-lsp-ruff` instead of using ruff's own language server?

Ruff ls doesn't have code formatting.

As of right now, pylsp has some nice features that ruff doesn’t cover yet, like the jedi, rope, and black stuff. The editor I’m currently using doesn’t easily — at all? — support multiple servers at once. Today, that means it’s easiest for me to use it as a plugin under pylsp.

I read this comment on the train to work today. First thing that happened at work was that somebody had disabled the linting stage because of exactly this error.

(of course I should have pinned versions...)

it's version 0.x - breakages are expected

Reply on news.ycombinator.com