Import resolution issue - pyright not using correct python

[synapticarbors]

I'm running into an issue where pyright does not select the python environment defined by the python executable that is found on the $PATH. My understanding from the docs is that if python.venvPath and python.pythonPath are not set, then pyright should "use the default Python environment (i.e. the one that is invoked when typing python in the shell)."

As an example, I have a python file called foo.py that contains:

import requests

if __name__ == "__main__":
    print(requests.__version__)

I activate python python environment using pixi (but the same is true with a conda env), such that:

$ which python
/Users/xyz/opt/pixienvs/pyright-test/.pixi/envs/default/bin/python

and

$ which python3
/Users/xyz/opt/pixienvs/pyright-test/.pixi/envs/default/bin/python3

if I then run:

$ ~/.local/share/nvim/mason/bin/pyright --verbose foo.py

Auto-excluding **/node_modules
Auto-excluding **/__pycache__
Auto-excluding **/.*
Execution environment: python
  Extra paths:
    (none)
  Python version: 3.13
  Python platform: Darwin
  Search paths:
    /Users/xyz/.local/share/nvim/mason/packages/pyright/node_modules/pyright/dist/typeshed-fallback/stdlib
    /Users/xyz/Projects/tmp/pyright_test
    /Users/xyz/Projects/tmp/pyright_test/typings
    /Users/xyz/.local/share/nvim/mason/packages/pyright/node_modules/pyright/dist/typeshed-fallback/stubs/...
    /Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9
    /Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/lib-dynload
    /Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/site-packages
Found 1 source file
Could not resolve source for 'requests' in file '/Users/xyz/Projects/tmp/pyright_test/foo.py'
  Looking in root directory of execution environment 'file:///Users/xyz/Projects/tmp/pyright_test'
  Attempting to resolve using root path 'file:///Users/xyz/Projects/tmp/pyright_test'
  Finding python search paths
  Executing interpreter: 'python3'
  Skipping '/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/lib/python39.zip' because it is not a valid directory
  Received 3 paths from interpreter
    file:///Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9
    file:///Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/lib-dynload
    file:///Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/site-packages
  Looking in python search path 'file:///Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9'
  Attempting to resolve using root path 'file:///Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9'
  Looking in python search path 'file:///Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/lib-dynload'
  Attempting to resolve using root path 'file:///Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/lib-dynload'
  Looking in python search path 'file:///Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/site-packages'
  Attempting to resolve using root path 'file:///Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/site-packages'
pyright 1.1.389
/Users/xyz/Projects/tmp/pyright_test/foo.py
  /Users/xyz/Projects/tmp/pyright_test/foo.py:1:8 - warning: Import "requests" could not be resolved from source (reportMissingModuleSource)
0 errors, 1 warning, 0 informations
Completed in 0.184sec

It appears that the python3 that pyright is finding is file:///Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9, which is incorrect, unless I'm not understanding the documentation correctly. If I pass in the python path explicitly I get the expected behavior:

$ ~/.local/share/nvim/mason/bin/pyright --verbose --pythonpath $(which python3) foo.py
Setting pythonPath for service "<default>": "/Users/xyz/opt/pixienvs/pyright-test/.pixi/envs/default/bin/python3"
Auto-excluding **/node_modules
Auto-excluding **/__pycache__
Auto-excluding **/.*
Assuming Python version 3.12.7.final.0
Execution environment: file:///Users/xyz/opt/pixienvs/pyright-test/.pixi/envs/default/bin/python3
  Extra paths:
    (none)
  Python version: 3.12.7.final.0
  Python platform: Darwin
  Search paths:
    /Users/xyz/.local/share/nvim/mason/packages/pyright/node_modules/pyright/dist/typeshed-fallback/stdlib
    /Users/xyz/Projects/tmp/pyright_test
    /Users/xyz/Projects/tmp/pyright_test/typings
    /Users/xyz/.local/share/nvim/mason/packages/pyright/node_modules/pyright/dist/typeshed-fallback/stubs/...
    /Users/xyz/opt/pixienvs/pyright-test/.pixi/envs/default/lib/python3.12
    /Users/xyz/opt/pixienvs/pyright-test/.pixi/envs/default/lib/python3.12/lib-dynload
    /Users/xyz/opt/pixienvs/pyright-test/.pixi/envs/default/lib/python3.12/site-packages
Found 1 source file
pyright 1.1.389
0 errors, 0 warnings, 0 informations
Completed in 0.191sec

It almost looks like when pyright runs python3 to configure the environment for import resolution, it is happening in a subshell that didn't inherit the $PATH. To support this, in a terminal with no environments activated, running python3 -m site gives back the site-packages that pyright is finding.

Has anyone seen this behavior before? I'm just running across this on a new machine. On my previous computer (running a much older version of MacOS) pyright behaved as expected. I've also tested older versions of pyright on this machine and they all behave the same way.

For completeness, this minimal example was run on the command line, but I spotted the issue initially in neovim when using Mason and nvim-lspconfig. Tests were on a machine running MacOS 15.1

[erictraut]

Moving to a discussion topic since this is not a bug report but instead a configuration question.

[wizeng23]

+1, one of my teammates got this same issue. The only (hacky) fix they found is deleting /Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework. Strangely, they're the only person on our team to get this issue