FileNotFoundError on hallucinated site-packages path when starting debug session in VSCode

[hheimbuerger]

When I run my project in the VSCode debugger, I get a FileNotFoundError: [WinError 3] The system cannot find the path specified: 'C:\\Users\\me\\AppData\\Roaming\\Python\\Python39\\site-packages'. As far as I can tell, it's pretty early on in the runpy.py lifecycle.

This path is incorrect. It is not where my current Python installation's site-packages lives and I'm also running out of a virtualenv, which also doesn't point to that directory. I cannot figure out where VSCode takes this directory from.

This is a fresh installation of Python 3.9 (using the official installer from python.org), from which I created a fresh venv, which I then selected as the Python interpreter in my project.

There's something very broken in my VSCode installation, but I don't know how to troubleshoot it. For reference, if I choose another (system) Python interpreter, I get FileNotFoundError: [WinError 3] The system cannot find the path specified: '', which also seems like an absurd error message.

I already reinstalled the Python extension, but that didn't make a difference. I'm happy to debug further, but the fact that all of this is coming out of the exec(code, run_globals) line hides the call stack.

The path is most likely from an earlier Python installation, one that I had installed with winget. But where is VSCode taking it from and how can I tell it to stop doing so?

[hheimbuerger]

[hheimbuerger]

I can run my project just fine from the shell (after activating the venv manually first). I just cannot debug it in VSCode.

I also have a Jupyter notebook using the same virtualenv, that I'm using out of VSCode. That's also working fine. The problem appears to be limited to runpy.py.

Could this file have gotten modified somehow? But wouldn't reinstalling the Python extension reset that file, too?

[hheimbuerger]

I just found out that runpy.py is a file from Python, not from VSCode. Now I'm even more confused. So no point in trying to reset it then, because this is from a Python installation I installed from scratch an hour ago.

[brettcannon]

This path is incorrect. It is not where my current Python installation's site-packages lives and I'm also running out of a virtualenv, which also doesn't point to that directory. I cannot figure out where VSCode takes this directory from.

I'm not sure how you installed Python, but I believe that path comes from either the python.org installer of Python or the portable install.

I can run my project just fine from the shell (after activating the venv manually first). I just cannot debug it in VSCode.

Did you create the virtual environment from the same version of Python you're using to launch the debugger with (you can print out what sys.executable says to figure that out)?

[hheimbuerger]

This path is incorrect. It is not where my current Python installation's site-packages lives and I'm also running out of a virtualenv, which also doesn't point to that directory. I cannot figure out where VSCode takes this directory from.

I'm not sure how you installed Python, but I believe that path comes from either the python.org installer of Python or the portable install.

In the latest iteration (again: there were a couple of iterations before that, one of which apparently left a trace I cannot find), I simply downloaded the installer from python.org (win-x64). I installed it to 'all users', meaning the executable is in c:\Program Files\Python39. That's where I want it.

I can run my project just fine from the shell (after activating the venv manually first). I just cannot debug it in VSCode.

Did you create the virtual environment from the same version of Python you're using to launch the debugger with (you can print out what sys.executable says to figure that out)?

Yes, I did. I specifically ran c:\Program Files\Python39\python.exe -m venv .venv to create the virtualenv.

Running python -c "import sys; print(sys.executable)" in the venv actually just points to the executable in the virtualenv. This might be a speciality of the Windows version that it doesn't create a symlink as you might have expected on other platforms.
But pyvenv.cfg in points to home = c:\Program Files\Python39, as I would expect it to.

[hheimbuerger]

I figured out that if in the launch.json, I change justMyCode to true, I can launch my project from inside VSCode again.
I hate not being able to debug into library code, but I guess it's better than not being able to debug at all.

This is a fairly simple Flask project. (Sorry that I didn't mention this earlier, it did not seem relevant, as the issue pointed to something with the Python installation.)

Now I'm even more confused: is that the solution, or does it just hide an underlying issue?

Was this exception for some reason to be expected, and I just got stuck on it, because I had 'stop on all breakpoints' enabled? But I still don't understand why it would raise an exception over this imaginary path...

[brettcannon]

Was this exception for some reason to be expected, and I just got stuck on it, because I had 'stop on all breakpoints' enabled?

Ah, that's the key detail. So this is expected because Python's stdlib is "library code", and runpy is raising an exception by doing EAFP-style ("easier to ask forgiveness than permission") programming which is totally legitimate (notice how the line you broke on is in a try block).

So everything is working as expected, but you're discovering how noisy "stop on all breakpoints" can be when you include code you don't control which may use a coding style which isn't amenable to "stop on all breakpoints".

[hheimbuerger]

I guess that's a possibility. And what changed is that at some point, I enabled the Raised Exceptions breakpoint halting flag, while debugging something.

Still confused where it has that path from, though. Is it hardcoded into the Python interpreter? That's so unlike Python.

But I guess I'm gonna let this rest for now, even though I don't fully understand everything happening here.

[brettcannon]

Is it hardcoded into the Python interpreter? That's so unlike Python.

It's probably pre-computed, yes. And it's actually very typical on a per-OS basis in order to know where to look for things.

But I guess I'm gonna let this rest for now, even though I don't fully understand everything happening here.

Since Python is open source you could trace through Python's start-up code if you really wanted to dig into and learn about how Python starts up and gets its set up.