Pryoritize reslove_python in venv selection

[lucaSartore]

According to the documentation here:

Python dependencies and virtualenv

nvim-dap-python by default tries to detect a virtual environment and uses it
when debugging your application. It looks for:

• The environment variables VIRTUAL_ENV and CONDA_PREFIX
• The folders venv, .venv, env, .env relative to either the current
  working directory or the root_dir of a active language server client. See
  :h lsp.txt for more information about the latter.

If you're using another way to manage virtual environments, you can set a
custom resolve_python function:

require('dap-python').resolve_python = function()
 return '/absolute/path/to/python'
end

nvim-dap-python should by default try to automatically find the virtual environment using environment variables, and specific folders, however a user of the plugin can override those settings with resolve_python.

However the code is not consistent with this description, and due to the ordering, environment variables override resolve_python and resolve_python override the venv folders.

I switched the order so that if the user defines resolve_python he has full control control on the environment, which I think is the desired behaveour.

[mfussenegger]

Is there a scenario where the env variable is set but incorrect?

I'd actually tend to update the documentation so that users don't have to re-implement that part if they customize it.

[lucaSartore]

I originally came across this issue because the venv-selector
plugin wasn’t working properly and couldn’t debug Conda environments. While investigating, I noticed that the behavior didn’t match the documentation, and with my change the issue was resolved.

After looking into it more closely, I realized that venv-selector itself has a bug: it sets the environment variable incorrectly. I’ll be sending a PR to venv-selector to fix that, which means this PR here is no longer strictly necessary.

That said, I still think the behavior described in the documentation—giving full control to resolve_python—is more desirable, since it ensures users can always override the defaults if they want. But I’ll leave the decision up to you. Once venv-selector is fixed, this PR becomes optional.

EDIT: I created the PR in venv-selector, I link it here for trackability: linux-cultist/venv-selector.nvim#220

[mfussenegger]

That said, I still think the behavior described in the documentation—giving full control to resolve_python—is more desirable, since it ensures users can always override the defaults if they want

I think if it is more desirable depends on whether if there is a scenario where VIRTUAL_ENV is wrong (and not because of a bug in some other software that ought to be fixed)

If there is, you're right, if there isn't, then the current logic means users might not have to re-implement the VIRTUAL_ENV case.
I currently can't conceive of a legitimate case where it would be incorrect.

But leaving this open for more feedback. If anyone has a case where VIRUTAL_ENV is set to the wrong python venv it would be good to know.