How to use pyright version from the environment not the bundled pylance version

[BrandonNav]

I work in a large codebase with many engineers and we are exploring standardising our workflow with VSCode and Pylance. Along with this we wish to use pyright for our CI checks.

Unfortunately, we are having trouble configuring the developer environment and the CI environment as pylance uses a bundled version of pyright. This causes us to have the following 2 issues:

1. VSCode will automatically update the extension which can cause new typing issues to surface for code unrelated to a developers work. We can advise our team to lock to a particular version of pylance but this causes difficulties due to having to broadcast when to upgrade. This causes additional friction when we wish to upgrade pyright and we need to determine which pylance to install, etc

2. For our current code, we need to be on the latest version of pyright (1.1.308) to address certain typing issues but the current release version of pylance (v2023.5.20) bundles pyright 1.1.306 and the current pre-release (v2023.5.21) bundles pyright 1.1.307. We are in a chicken-and-egg situation where either our CLI fails or our development environment displays errors.

I am wondering if there is a way to configure pylance to use the version of pyright that is accessible from the environment? This would mitigate the above issues for us.

[rchiodo]

I think the easiest solution would be to lock the pyright version to whatever the latest Pylance is using. You can write a script to pull down the changelog and parse it to find the pyright version in use.

You may also be just hitting differences in the CLI of pyright versus pylance, which is explained here:
https://github.com/microsoft/pylance-release/blob/main/USING_WITH_PYRIGHT.md

[debonte]

For our current code, we need to be on the latest version of pyright (1.1.308) to address certain typing issues

For what it's worth, we should be shipping a new prerelease build of Pylance today, which will be based on the latest Pyright release.

[BrandonNav]

Thanks for your replies @rchiodo and @debonte.
I have put a more thorough reply below with Eric's response

[erictraut]

We endeavor to minimize the differences between pyright and pylance. During most weeks, I release a single update to pyright on Tuesday evening, and the pylance team releases an update on Wed. The insiders build of Pylance uses the latest pyright build, so it's normally in sync with the latest release of pyright (except for the ~18-hour window between Tuesday evening and Wed afternoon). This past week was unusual in that I published two versions of pyright (1.1.308 and 1.1.309) due to an unusually large number of fixes and feature enhancements. Your experience with 1.1.308 is therefore likely to be an anomaly. If you experience a similar situation in the future, it would be helpful for us to learn about the details.

You mentioned that you need to be on 1.1.308 for your code base. Am I correct in assuming that you recently started to use pyright and that some of the issues you encountered were recently reported and fixed in 1.1.308? Barring any regressions, this should be less of an issue now that your code base type checks with pyright.

In addition to the suggestion from @rchiodo about pinning the version of pyright, another option is to have your team run the pyright VS Code extension rather than pylance. You'd forego the more advanced language server features provided by pylance in this case, so that's likely not a very appealing option, but I figured I'd throw it out there.

As for your suggestion for allowing pylance to use an arbitrary version of pyright, that would require pylance to be built in a very different manner than it is currently, so it would be a heavy lift. It would also require that we maintain a formalized and stable interface contract between pylance and pyright code, and that would restrict our ability to refactor and modify internal code at will (which we do frequently today). That's something that neither myself (the main pyright maintainer) nor the pylance team would find very appealing. So I don't think that's a viable option.

[blakeNaccarato]

So @erictraut one alternative is to use the Pyright VSCode Extension. I try this and see that it can't be used side-by-side with Pylance. Having Pylance enabled disables the Pyright VSCode Extension.

Would it be possible to tell Pylance to go ahead and keep doing the advanced language and refactoring features using its bundled Pyright, while letting the Pyright VSCode Extension use the local .venv pyright or local pyright in node_modules to type check? This would require telling Pylance to offload type checking on to the Pyright extension, while still doing what it does best using its bundled tooling.

I'm trying to figure out how I can keep Pylance mostly up to date, while incrementally upgrading pyright as new behavior/rules change. If only there was a way for the average user experience to be enabled "magically" by Pylance, with an escape hatch (I consider the Pyright VScode Extension could somehow act as that escape hatch) for advanced development and staying in sync with CI and such.

[rchiodo]

See this issue. We've added a way to do (I believe) exactly what you've asked for:
#5207

[blakeNaccarato]

Awesome! I can see from the issue discussion how it would be impractical to implement it any other way besides running a vanilla copy of pyright alongside Pylance's internal fork. I'll have to try the new setting and see how it goes!

Does the vanilla pyright copy use Pylance's bundled stubs?

For other visitors to this thread, in case that performance tradeoff is too steep, I've had good results minimizing CI/local differences between Pylance/pyright lately like this:

• Distribute a VSCode "profile" in the repo with Pylance pinned, instruct devs to associate their repo clone folder with that profile (they can still mix their own global settings.json into the profile), and pin Pylance in Devcontainer config as well.
• Tell CI what pinned Pylance version you're using and jakebailey/pyright-action will select the matching pyright version.
• Add microsoft/python-type-stubs as a submodule to the repo and point to its stubs directory in pyproject.toml:tool.pyright.stubPath (respected by Pylance).
• Optionally use Mend Renovate's regex rule (it's kinda like Dependabot) to keep stubs and any Pylance/pyright pins specified various places up to date.

The trick is to match up both the Pylance/pyright versions as well as the stubs, since pyright in CI doesn't have Pylance's bundled stubs.

[rchiodo]

Yeah it points the stubs path for Pyright to the bundled stubs that ship with Pylance. Hopefully that's what people expect. Might need to make that configurable if their CI isn't using the pylance stubs.

[blakeNaccarato]

That makes sense by the reasoning that a setting should minimally effect the desired change.

That bundled stubs can also cause CI/local differences is a separate concern, though it may not be entirely clear from the user (or project maintainer) side that they are distinct sources of the diagnostic differences.

So it is possible that this new setting might give the false impression that all CI/local differences will be resolved by pinning pyright, and yet the bundled stubs still give rise to some differences.

Maybe this could be alluded to concisely in the new setting's hover hint tooltip? E.g. pointing to the existing python.analysis.stubPath setting as another source of diagnostic output variation.

Either way, I appreciate the presence of this new setting! The details will shake out if/when users engage with this setting and either are or are not surprised by its behavior.