Make ruff dependency optional

[rassie]

I know the issue title sounds weird for a "ruff language server", but please hear me out, it might make sense in the end. Please keep in mind that I don't quite know how to solve this properly, but I do see the need for it.

If we consider a developer who is part of a team effort on a particular project, we can subdivide all the tools they are using in roughly two categories: developer-provided and project-provided.

In any given project, its development team converges on some common ground regarding linting, code formatting etc., including tool versions, so using ruff version X on a project is a project-based decision, reflected in this project's dependencies. Other projects might be using a version Y, so having a global ruff binary installed might be wrong in these circumstances.

However, using an IDE/editor with LSP support and its particular ruff integration is a decision by the developer for their own comfort. So whether or not they are using VSCode or Emacs or Notepad is not something that should affect other team members. In this case, adding ruff-lsp to the project's dependencies is in best case useless for the people using e.g. VSCode and could be considered rude in some teams ("we don't commit .vscode/ after all either").

So we have a situation where ruff-lsp should probably be kept out of projects' dependencies and installed (user)-globally, but ruff itself needs to be part of a project. In many cases, there would be no need for a (user)-global ruff at all, however it's getting installed by ruff-lsp as a dependency nevertheless. It would be nice if there was a way to install it separately and explicitely.

[charliermarsh]

Is it possible to solve this problem by using the path or interpreter settings? You can provide a path to any Ruff binary, or a path to a Python interpreter, and the LSP will use those instead of the version that ships with the LSP. (In the VS Code extension, this gets picked up "automatically"; ruff-lsp doesn't do that yet, but could in the future.)

[rassie]

Yes, of course, even though it's a small risk factor. It's a matter of remembering to use poetry run ruff in the CLI instead of ruff in a project every time, even if you configured all of your editors correctly. ruff-lsp also depends on a minimally-required version of ruff while a project can depend on an earlier or later version, so using the wrong one can lead to surprising results, especially several months down the line.

This is not a ruff-lsp-specific problem though and at least one other linter-specific language server, ESLint language server, does not install the actual binary, explicitely defining the behaviour as

The extension uses the ESLint library installed in the opened workspace folder. If the folder doesn't provide one the extension looks for a global install version. If you haven't installed ESLint either locally or globally do so by running npm install eslint in the workspace folder for a local install or npm install -g eslint for a global install.

I would like to stress that I would prefer ruff-lsp to not install the ruff binary, but I don't consider it doing so a deal-breaker, for the exact reasons you provided -- it's possible to configure, so there is an acceptable workaround. I just would appreciate if you considered it.

(There is talk of revamping extras handling in Python packaging universe, so it might become possible for the end-user to exclude ruff from installation with either default-extras or negative extras. That would be great and maybe it's easier to just wait for it to happen)

[NeilGirdhar]

Yes, of course, even though it's a small risk factor. It's a matter of remembering to use poetry run ruff in the CLI instead of ruff in a project every time,

It might help you to set up your shell to do poetry shell whenever you enter the project directory using this https://github.com/darvid/zsh-poetry extension. No need to do poetry run after that.