How does Pyrefly expect the interpreter be passed to it via LSP?

[InSyncWithFoo]

I maintain the Pyrefly plugin for JetBrains IDEs. A user just filed an issue asking if the plugin could pass the interpreter to Pyrefly directly. How do I do that?

[connernilsen]

Oh great question! I don't think we support that directly at the moment, but we can look at adding it in the future if the following doesn't work for most cases.

At the moment, if someone wants to support a specific interpreter for a project, they should create a pyrefly.toml or pyproject.toml in the directory their project is in. Right now, if the interpreter is in a venv, we currently look at the same directory as that config to find it (which means the pyrefly.toml can be empty or the pyproject.toml won't need a [tool.pyrefly] section). Otherwise, we'll grab the first interpreter we can find on the path.

If that's not the interpreter they're looking to use, they can explicitly specify it with python_interpreter = <path>. The explicit interpreter is generally not a great idea though, since as Kyle mentioned below, it's unlikely to be consistent between systems.

I'm going to work on adding support for more Python environments in our automatic environment finding logic soon.

Note: I edited this to make a bit more sense, but I'll leave it to Kyle since he'll know the most about it

[kinto0]

The config file interpreter setting should not be necessary and can be a hinderance to development: different machines have different pythonpaths and different IDEs have different ways of dealing with them. We solve it in VSCode and I'm confident we can solve it for Pycharm too.

The VSCode extension includes logic that asks the Python extension for it (the python extension is where the version selector lives in VSCode and is why we have a dependency on that extension). Even though the Microsoft Python extension exists in Pycharm, I imagine the Pycharm extension might want to use Pycharm's methodology for selecting a Python interpreter.

We tell the language server about these settings by hooking into the workspace/configuration request through middleware here.

The full flow goes like this:

• client->server didChangeConfiguration notification from python interpreter updates in the IDE (needed to be added to extension)
• server->client requests configuration for all workspace folders (from didChangeConfiguration handling within language server) (built into language server)
• client->server sends settings including workspace interpreter path as pythonPath (needed to be added to extension)

Happy to help if you have other questions. Thank you again for your help!!

[connernilsen]

@InSyncWithFoo I misunderstood some of what was going on, so changed my answer a bit. @kinto0 knows more about what's going on than I do here, so I'll let him handle this 😅

[dam5s]

Thanks everyone for looking into this. I am the one that asked about this. I'm trying to run the pyrefly plugin in PyCharm while using uv for managing package versions and the python version.

I find it particularly odd that the pyrefly binary lives in the same directory as the python binary in the virtualy env that was setup by uv, so I would have expected it to directly recognize its own virtualenv? Obviously I am not that familiar with how this is all tied together... thanks for your help.

[InSyncWithFoo]

Thanks, @kinto0 and @connernilsen; the responses were very helpful and have certainly saved me the efforts of going through the codebase.

I got it to work by sending a workspace/didChangeConfiguration notification after initialized. Pyrefly will then, indeed, send a workspace/configuration request asking for the python section, to each item of which I respond with {"pythonPath": "~/project/.venv/bin/python"}.

There is one problem though: Pyrefly will first publish diagnostics using the inferred (global) interpreter, which are then invalidated once it receives the correct interpreter, causing a "flashing" effect that could potentially be annoying for some. This is but the cherry on top; Pyrefly is actually querying for information and indexing things twice (one time for each interpreter) but once should be enough.

I think Pyrefly should instead send workspace/configuration requests on its own without being first prompted with /didChangeConfiguration.

[kinto0]

Thanks, @kinto0 and @connernilsen; the responses were very helpful and have certainly saved me the efforts of going through the codebase.

I got it to work by sending a workspace/didChangeConfiguration notification after initialized. Pyrefly will then, indeed, send a workspace/configuration request asking for the python section, to each item of which I respond with {"pythonPath": "~/project/.venv/bin/python"}.

There is one problem though: Pyrefly will first publish diagnostics using the inferred (global) interpreter, which are then invalidated once it receives the correct interpreter, causing a "flashing" effect that could potentially be annoying for some. This is but the cherry on top; Pyrefly is actually querying for information and indexing things twice (one time for each interpreter) but once should be enough.

I think Pyrefly should instead send workspace/configuration requests on its own without being first prompted with /didChangeConfiguration.

Hmm... we should already do that. We don't send a didChangeConfiguration in vscode unless the interpreter has changed.

We configure on startup, which requests the configuration for each workspace folder already. Could the editor be responding with an empty config to the first request?

[InSyncWithFoo]

@kinto0 I just rechecked. The client always responds with the correct path; however, what got Pyrefly to work was neither /didChangeConfiguration nor the responses to /configuration, but that a pyproject.toml file exists. Here are the traces, in case you want to look into it further.

(By the way, Pyrefly sends a lot of /publishDiagnostics notifications, each mere milliseconds apart.)

[anzhi0708]

Hey everyone! I haven’t looked closely at the details of your discussion, but while using Helix (the text editor) with uv (the package manager), I found that pyrefly couldn't detect the virtual environment created by uv. In this thread, I discovered a TOML key called tool.pyrefly.python_interpreter, and after manually setting it to ./.venv/bin/python, type hints and autocompletion for third-party packages started working properly in Helix. Just wanted to let you guys know — and thanks for the work!

By the way, I’d really love to see a comparison between pyrefly and ty in the official documentation!

[yangdanny97]

By the way, I’d really love to see a comparison between pyrefly and ty in the official documentation!

IMO it's a little too early to make comparisons, since both typecheckers are in alpha with missing/unsupported features and design decisions can change based on early adopters' experiences. Any quantitative comparison we make now would be outdated in a matter of weeks.

[kinto0]

@kinto0 I just rechecked. The client always responds with the correct path; however, what got Pyrefly to work was neither /didChangeConfiguration nor the responses to /configuration, but that a pyproject.toml file exists. Here are the traces, in case you want to look into it further.

(By the way, Pyrefly sends a lot of /publishDiagnostics notifications, each mere milliseconds apart.)

Sorry about the issue and our slow timeline in addressing it @InSyncWithFoo - we found what I think is the culprit and it should be fixed in 0.22.0.

[github-actions[bot]]

This issue has someone assigned, but has not had recent activity for more than 2 weeks.

If you are still working on this issue, please add a comment so everyone knows. Otherwise, please unassign yourself and allow someone else to take over.

Thank you for your contributions!

[kinto0]

closing. please open a new issue if there are other issues.