Meta issue: editor integrations

[charliermarsh]

Creating a parent issue to track and document the state of ruff's editor integrations.

[charliermarsh]

We should support and document integration with VS Code and PyCharm at the very least. I know there was some prior work + discussion in #118.

[charliermarsh]

Part of the work here could be making @harupy's VS Code extension publicly available. I'm happy to take that on if needed.

[Seamooo]

I've been playing around with the microsoft lsp as a way of making ruff available to a wider number of editors (particularly vscode and coc-nvim). The major blocker for me is that the main function for linting ruff::linter::lint_path only accepts a Path for the source. There's currently no public interface for linting from contents, or lower level access to the checking functions (i.e. check_path is private and check_ast requires autofix::fixer::Mode but autofix is private)

[charliermarsh]

I haven’t had time to dig in on this, but is the solution to exposure lint_path and then have the LSP use the ruff crate as a library? Or do we need to expose that functionality as a binary / CLI? I’m happy to do whichever’s necessary.

[charliermarsh]

In other words: if I added a lint_path function that was publicly exposed (with public args etc.), would that unblock this?

[Seamooo]

The critical blocker is being able to take a source input, rather than just the path, whether that be in a publically exposed api or from stdin, both are viable. As a preference working with a public api would be nicer, also leaving open the opportunity for incremental linting.

[charliermarsh]

Ok cool, very doable. Will put something together.

[charliermarsh]

(I added some documentation for PyCharm.)

[vikigenius]

@charliermarsh

Comenting on your question from #289 (comment) here since it's a more relevant thread.

What does it take to enable others to use the LSP from VS Code and elsewhere?

Alternatively most python language servers are expected to be able to installed as a python package itself. So just distributing the language server as a python package using maturin would be enough.

Once that is done, the editors that support lsp would start developing clients to interact with the ruff language server.

Although personally I would like to have a general purpose language server to enable completions and use ruff as just an additional checker either as a separate binary or as an extension. Because the existing language servers for python are implemented in python and extremely slow or implemented in JS/TS (pyright) which I don't like.

Now that you have shown what we can do with Rust for python ecosystem hopefully in the future we can build an entire language server from the ground up in Rust for Python and have ruff as a checker extension for it. Like how Rust Analyzer is for Rust.

[charliermarsh]

👍 This makes sense! I want to spend some time exploring this soon (maybe this coming week), and putting together some official extensions. I use PyCharm, not VS Code, so I’m less familiar with the ecosystem (I need to understand the relationship between the LSP implementation, Ruff as a library, and then the actual editor extensions or actions and how those are distributed). But I do want Ruff to have the best possible editor support for VS Code given its popularity :)

[vikigenius]

Yep. As long as you have good language server support following the protocol. The people working on the editors will automatically start working on a client if the server is good/popular enough.

For instance, the moment we have a language server for ruff, I will try to contribute a client to Emacs https://github.com/emacs-lsp/lsp-mode so that I will be able to use it in Emacs. Similar would happen to all editors I am sure.

So the question basically becomes should the language server be a separate implementation? Or should it be somehow integrated into the same Repo (different crate) like how Rust-Analyzer does it for example.

I know @Seamooo had an inital prototype implementation here https://github.com/Seamooo/ruffd it is a good POC for what a language server will look like in general.

[vikigenius]

The LSP specification https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/ is actually very readable unlike most specifications if you want a reference

Additionally something to consider is that all language servers will have different capabilities that they supports. A hypothetical ruff-language-server will support formatting related capabilities such as codeActionProvider and diagnosticsProvider.

But it won't support static checking and completion capabilities like completionProvider declarationProvider (goto declaration) etc.

A language server like Rust-Analyzer basically supports everything since it integrates, formatting, diagnostics, completion etc. all in one.

I know that linting itself is a huge task that you are taking on, but it might be useful if things like the parsing, AST/CST logic etc. can be well defined and reusable enough that in the future we can think of adding completion and type checking related capabilities as well for an all in one rust based python language server.

[charliermarsh]

Awesome. I'd like it to be in the same repo, if possible. We can use @Seamooo's implementation as a starting point (or would it ever make sense to build atop something like tower-lsp? I have to do some research here).

You're exactly right that it'd be good to design this with future capabilities in mind. Ruff already supports auto-fix, but auto-formatting is another good example of a capability that would be interesting to explore within the scope of the project.

[charliermarsh]

(Let's keep using this issue to discuss for now, and I'll open something else specific to the LSP if / when I have work ready for review / feedback.)

[vikigenius]

Oh, I didn't know about tower-lsp before. It seems like a pretty useful abstraction. The protocal itself is not that hard to implement as can be seen from the prototype implementation https://github.com/Seamooo/ruffd

But having something like tower-lsp will definitely make it easier and maybe more easily maintainable (hopefully).

[b4rlw]

Are there any plans for neovim integration?

[Seamooo]

Definitely like the look of tower-lsp, and would be a big step for maintainability. Only reservervations would be having to dig into how it does scheduling as request ordering is important in the case of mutations.
If we're looking to create a code action provider for fixes, the api exposing Check, rather than Message, and making Fix a public type should enable everything.

[Seamooo]

@beatslikeahelix https://github.com/Seamooo/ruffd works with coc.nvim admittedly there isn't a release candidate right now as it's very POC. To get it to work you can add below to your coc-settings.json

{
	...
	"languageserver": {
		...
		"ruffd": {
			"command": "/path/to/ruffd",
			"filetypes": ["python"],
		}
	}
}

(obviously the ellipses indicating any other config you might have there)

[charliermarsh]

I'm going to try building a VS Code extension atop ruffd.

[fannheyward]

coc-pyright has added ruff support, only lint for now.

[charliermarsh]

@fannheyward - That's awesome! Thank you for doing that. I'll plug it in the Ruff docs.

[JafarAbdi]

For those who are using neovim, you could integrate ruff directly with efm just add the following lines to your config file

[charliermarsh]

@koxudaxi - Awesome! I'll give it a try today.

I'm still figuring out the roadmap for ruffd. Right now, I'm slightly more interested in using the LSP from https://github.com/charliermarsh/vscode-ruff and seeing if I can leverage it outside of VS Code (e.g., in Sublime Text).

[koxudaxi]

@charliermarsh
OK, I will check the repository. Thank you.
I feel the speed is not bad for only applying to 1 file using CLI from the plugin.
What LSP request type is supported by ruffd?
Should I check the source code? 😅

[charliermarsh]

The most relevant stuff in vscode-ruff is here -- the bundled Python server running on pygls. You can see the supported actions in the @LSP_SERVER.feature decorators.

[charliermarsh]

(I know you asked about ruffd, but right now vscode-ruff is more familiar to me.)

[charliermarsh]

@koxudaxi - Does the extension surface errors in the editor? Or is it meant to be invoked with the "Run Ruff" action?

[koxudaxi]

This version runs ruff --fix, and it doesn't show any message, including an error from the command.
I will expect to show the message in the message window like console window or/and highlight the code with the error message on the editor in future versions.
If ruff can inspect the code quickly, we can run the ruff by every user action(changing code).
Or, Can ruff partial inspection with cache?

[fannheyward]

Run ruff --fix for a file when the file is saved

I did ruff linting in coc-pyright, also provided fix code action to pick and use.

But for ruff --fix on save, I don't have a strong desire to add. Apply fixes on save may change the whole file that bring unpredictable changes.

This is my OWN opinion, what do you think for this feature?

[koxudaxi]

But for ruff --fix on save, I don't have a strong desire to add. Apply fixes on save may change the whole file that bring unpredictable changes.

The plugin is designed to prevent unexpected changes.

1. This is an optional feature. Users can enable the feature from the settings panel.
2. The plugin invokes ruff and gives the source code as stdin. And The plugin gets formatted code from stdout. ruff command doesn't write the file directly. PyCharm writes the file.
3. PyCharm manages the write action with exclusive access control.

[charliermarsh]

My general take is that fix-on-save should be entirely opt-in and disabled by default.

[koxudaxi]

I agree with you. The feature is disabled by default.

[charliermarsh]

If ruff can inspect the code quickly, we can run the ruff by every user action(changing code).

The Ruff VS Code plugin just runs constantly on the open file, I think it's fast enough to do it on-user-change.

[tsugumi-sys]

Are there any plans for helix-editor integration?

[cole-jacobs]

For instance, the moment we have a language server for ruff, I will try to contribute a client to Emacs https://github.com/emacs-lsp/lsp-mode so that I will be able to use it in Emacs. Similar would happen to all editors I am sure.

Any progress on this, @vikigenius ? Anything special I need to do to get this working in emacs?

[koxudaxi]

@charliermarsh
I have published version v0.0.3 of the ruff pycharm plugin.
I added the feature inspection and quick fix
Could you please try it? you can download it marketplace
If you feel good, I want to put the link on the ruff documents.

https://github.com/koxudaxi/ruff-pycharm-plugin

[charliermarsh]

@tsugumi-sys - I bet that https://github.com/charliermarsh/ruff-lsp would work with Helix, it's just a matter of configuring it.

Same for Emacs @cole-jacobs.

I can try to figure out how to integrate with those editors and add instructions to the ruff-lsp docs -- there are already a few examples, for Neovim and Sublime Text -- but would also love PRs to that effect.

[charliermarsh]

Done, thanks @koxudaxi!

[charliermarsh]

I'm going to close this for now since we have a good thing going with the LSP, VS Code extension, and so on. I'll file some issues on the LSP repo to figure out integrations with Emacs and Helix.

[fannheyward]

coc.nvim + ruff-lsp https://github.com/neoclide/coc.nvim/wiki/Language-servers#using-ruff-lsp

"languageserver": {
  "ruff-lsp": {
    "command": "ruff-lsp",
    "filetypes": ["python"]
  }
}

[charliermarsh]

Amazing, thanks @fannheyward, I'll add those to the docs.

[charliermarsh]

Added Helix docs in astral-sh/ruff-lsp#20 @tsugumi-sys.

[tsugumi-sys]

@charliermarsh
I can use ruff in my project now and Omg, ruff is so first and I love it! Thank you very much:)

[charliermarsh]

Yay, thanks so much for the kind words!

[kuator]

This is awesome!

[charliermarsh]

I spent a little bit of time installing lsp-mode with Emacs but couldn't figure out how to get ruff-lsp to work with it, just too unfamiliar with Emacs. If anyone is able to set it up, and wants to contribute instructions, it would be hugely appreciated.

See: astral-sh/ruff-lsp#19.

[charliermarsh]

@koxudaxi - Just wanted to say thanks again for building and maintaining the PyCharm plugin! I was playing with it today, and I love that you're surfacing the fix messages etc. in the UI.

[koxudaxi]

@charliermarsh
Last week, I added ruff to my project https://github.com/koxudaxi/datamodel-code-generator
After using ruff in the actual project, I am excited about ruff and the PyCharm integration.
I will continue to maintain and add features to the PyCharm plugin.

Thanks for the feedback and your fantastic project.

PS. After knowing your commit history on ruff. I contribute to OSS every day 😸