basedpyright icon indicating copy to clipboard operation
basedpyright copied to clipboard

add the `python.analysis.nodeExecutable` setting from pylance

Open dastanmoy96 opened this issue 11 months ago • 5 comments

This is more of a Pylance feature parity request. Basically:-

  1. Keep the pyright version up-to-date with the vscode extension/language server itself and suggest it as the recommended version. This leads to less duplicating of installs across different workspaces.
  2. Support custom Node.js interpreter path/module just like Pylance. If the above feature gets implemented than it follows suit that a custom Node.js Interpreter would allow the language server to use more amounts of memory, as subprocesses spawned by Visual Studio Code itself have a limitation to about 4GB (mentioned in Pylance's description) and in such cases it's recommended to use a custom Node.js interpreter to make Pylance launch as a separate process.

dastanmoy96 avatar Jan 21 '25 11:01 dastanmoy96

  1. Keep the pyright version up-to-date with the vscode extension/language server itself and suggest it as the recommended version. This leads to less duplicating of installs across different workspaces.

the fact that pylance works this way is the exact reason i created basedpyright in the first place. the way i see it, linters/type checkers should never be pinned to their IDE extension version. it should use the same version expected by your project's dependencies. this is especially important if your project has CI that runs basedpyright. you want its results to be consistent with what you see in your IDE.

if you don't care about any of that (eg. if your project is not dependendent on a specific basedpyright version or not dependent on basedpyright at all), you can still use the version bundled with the extension by adding the following to your .vscode/settings.json:

{
    "basedpyright.importStrategy": "useBundled"
}

the extension falls back to this mode if there's no basedpyright version installed. i'm not going to change the default because i strongly believe "fromEnvironment" is almost always the correct choice. but if anybody disagrees with my perspective, the option is always there to change it, so i don't see a problem here.

  1. Support custom Node.js interpreter path/module just like Pylance. If the above feature gets implemented than it follows suit that a custom Node.js Interpreter would allow the language server to use more amounts of memory, as subprocesses spawned by Visual Studio Code itself have a limitation to about 4GB (mentioned in Pylance's description) and in such cases it's recommended to use a custom Node.js interpreter to make Pylance launch as a separate process.

you can install basedpyright from npm instead of pypi and use whatever node interpreter you want. does that work for you?

DetachHead avatar Jan 21 '25 12:01 DetachHead

Thanks for the quick response.

I do understand your philosophy, and the solution to the first feature request is absolutely fine.

Regarding the second feature request though, I only asked for it to, well people who are still using the bundled version to use an external Node installation to avoid VSCode's sub-process memory constraints. The solution you suggested once again requires to duplicate basedpyright installs across workspaces, which is something I am not really keen on doing.

I know I am probably one of the edge cases who wants a feature like that, but hey I will probably try looking into a Pull Request myself if it's hard to implement.

dasTanmoy0096 avatar Jan 24 '25 18:01 dasTanmoy0096

ah i see, pylance has a python.analysis.nodeExecutable setting. happy to support this

if you're willing to make a PR that would be appreciated. if you need help with anything let me know, thanks!

DetachHead avatar Jan 25 '25 04:01 DetachHead

How big of a priority is this to implement? Currently facing the same issue here....Diagnostic Mode set to entire workspace and basedpyright starts crashing often, would be nice if this setting was implemented :3

RagelVarma avatar Jan 28 '25 08:01 RagelVarma

i prioritize issues by sorting by 👍 count (as well as changes i personally think are feasible / important), so adding a 👍 react will help

anyone is welcome to contribute a PR as well

DetachHead avatar Jan 28 '25 09:01 DetachHead

I would also support this. Although mostly for the second point.

I currently get: [Error - 10:45:08] Error occurred on background thread: {"code":"ERR_WORKER_OUT_OF_MEMORY"} [Error - 10:45:09] Error occurred on background thread: {"code":"ERR_WORKER_OUT_OF_MEMORY"}

<--- Last few GCs --->

[28706:0x11000ec0000] 22759 ms: Mark-Compact (reduce) 620.7 (819.4) -> 620.3 (732.9) MB, pooled: 0.0 MB, 253.83 / 0.00 ms (average mu = 0.766, current mu = 0.001) last resort; GC in old space requested [28706:0x11000ec0000] 23017 ms: Mark-Compact (reduce) 620.3 (732.9) -> 620.0 (711.9) MB, pooled: 0.0 MB, 258.46 / 0.00 ms (average mu = 0.628, current mu = 0.000) last resort; GC in old space requested

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory

[Error - 10:45:10] Server process exited with signal SIGABRT. [Error - 10:45:10] The basedpyright server crashed 5 times in the last 3 minutes. The server will not be restarted. See the output for more information.

In larger repos. In pyright, setting a higher memory allowance allowed things to work fine for those repos

ysheikh2 avatar Dec 08 '25 09:12 ysheikh2

as a workaround you can set the environment variable NODE_OPTIONS=--max-old-space-size=4096 which should work in the version of node bundled with basedpyright

DetachHead avatar Dec 09 '25 10:12 DetachHead