Inconsistent Debugging Behavior When Using Multiple Virtual Environments #13

New issue

Closed

opened 2025-12-20 02:55:27 +01:00 by Ghost · 1 comment

Ghost commented

2025-12-20 02:55:27 +01:00

I'm really frustrated with the debugging behavior in nvim-dap-python. It claims to detect the project's virtual environment, but it seems completely random. I switch between different projects, each with their own venv, and I consistently run into issues where it doesn't pick up the right environment.

Sometimes it defaults to a global Python installation instead of the one specified. I mean, come on, how hard can it be to get this right? There's no clear error message or indication of what the issue is. If you’re trying to help users streamline their debugging process, this inconsistency just defeats the purpose.

Also, the documentation recommends using setup in init.lua, but there’s no explanation of what this should look like if something goes wrong. It would be nice to have some troubleshooting steps rather than just vague instructions on where to set the path to the Python interpreter.

Could we get more transparency about how it detects the venv? Some clear examples of what to avoid would be useful instead of the vague suggestion that it will magically "detect" things. Why not just add an option to explicitly define which venv to use?

This is becoming a major headache, and frankly, it's a major roadblock for productivity. We need a solution that actually works reliably in real-world scenarios, not just in ideal conditions.

I'm really frustrated with the debugging behavior in `nvim-dap-python`. It claims to detect the project's virtual environment, but it seems completely random. I switch between different projects, each with their own `venv`, and I consistently run into issues where it doesn't pick up the right environment. Sometimes it defaults to a global Python installation instead of the one specified. I mean, come on, how hard can it be to get this right? There's no clear error message or indication of what the issue is. If you’re trying to help users streamline their debugging process, this inconsistency just defeats the purpose. Also, the documentation recommends using `setup` in `init.lua`, but there’s no explanation of what this should look like if something goes wrong. It would be nice to have some troubleshooting steps rather than just vague instructions on where to set the path to the Python interpreter. Could we get more transparency about how it detects the `venv`? Some clear examples of what to avoid would be useful instead of the vague suggestion that it will magically "detect" things. Why not just add an option to explicitly define which `venv` to use? This is becoming a major headache, and frankly, it's a major roadblock for productivity. We need a solution that actually works reliably in real-world scenarios, not just in ideal conditions.

mfussenegger commented

2025-12-20 06:56:30 +01:00

Owner

Could we get more transparency about how it detects the venv?

See https://codeberg.org/mfussenegger/nvim-dap-python#python-dependencies-and-virtualenv

This works reliably in real-world scenarios for me.

(Given your entitled tone I don't feel particularly motivated to help further here. Best guess is that your cwd doesn't match the project, and if you've multiple lsp instances across projects, it might pick the first. If that was the case #14 should help)

> Could we get more transparency about how it detects the venv? See https://codeberg.org/mfussenegger/nvim-dap-python#python-dependencies-and-virtualenv This works reliably in real-world scenarios for me. (Given your entitled tone I don't feel particularly motivated to help further here. Best guess is that your cwd doesn't match the project, and if you've multiple lsp instances across projects, it might pick the first. If that was the case https://codeberg.org/mfussenegger/nvim-dap-python/pulls/14 should help)