Python executable location with Conda on Windows

[ndaman]

It looks like with some venv managers, the python.exe executable is put inside the Scripts directory of the .venv, but for me (Conda/Mamba), the python executable is stored in the base venv directory. For example:

C:\Users\ndaman\mambaforge\envs\pickle\python.exe

is where the actual executable is, but it seems that the plugin is looking for it inside of

C:\Users\ndaman\mambaforge\envs\pickle\Scripts\

Is there any way to change where the plugin looks for the python executable? Thanks!

[linux-cultist]

The default settings for windows may actually be incorrect so it's good that you are reporting this.

The Readme has information about two plugin settings you can set yourself, one for the base environment and one for the envs. Search for Anaconda and you should find them.

Try those and let me know if it fixes your issue.

[ndaman]

Thanks! I have set the two paths correctly, the plugin has no trouble finding my venvs, it just cannot find or set the python executable for my venvs, and from what I've read in other issues this sounds like it is because Conda is placing the python.exe in a different place than other python package managers do on Windows. I decided to look at the code and it seems like I what I would need is a way to override the way that python_parent_path is set from system.lua.

[linux-cultist]

Ok :)

The plugin does assume that the python executable is in a certain place in the venv, that's true.

I could add some setting for controlling this though, specifically for Conda for windows.

[linux-cultist]

I read through this thread again and at least for me, Conda has two different locations on disk for the Base environment and the other envs.

If you run conda env list, what do you get? Here is mine:

# conda environments:
#
conda1                   /home/cado/.conda/envs/conda1
conda2                   /home/cado/.conda/envs/conda2
base                  *  /opt/anaconda

So for the base enviroment (controlled by $CONDA_PREFIX environment variable), its /opt/anaconda. And my other environments are under ~/.conda/envs/.

You mentioned above that:

the python executable is stored in the base venv directory. For example: C:\Users\ndaman\mambaforge\envs\pickle\python.exe

And this should not be the base environment since its called envs in the path - this should be the other environments.

So share the output from conda env list and things will probably become more clear for me. :)

[ndaman]

Here's the output:

# conda environments:
#
base                  *  C:\Users\ndaman\mambaforge
pickle                   C:\Users\ndaman\mambaforge\envs\pickle

Setting the paths is not a problem, and the plugin works fine at activating the .venv, it just cannot find the associated python executable. For example when I select the base venv :h checkhealth says:

Python virtualenv ~
- WARNING $VIRTUAL_ENV is set to: C:\Users\ndaman\mambaforge
  But no Python executables found in the virtualenv /Scripts directory.
  So invoking Python may lead to unexpected results.

[linux-cultist]

Ok thank you. I will add an option to set the python interpreter paths.. :)

[linux-cultist]

If you update the plugin now, you have the option to specify some anaconda options (LazyVim example below):

opts = {
      anaconda = { python_parent_dir = "" }
}

I decided to start adding sub-options under the "anaconda" setting, so thats why it looks a bit different from the other options.

If you set this to an empty string like above, the plugin should skip adding a python parent path (it wont add 'Scripts' in your case).

Please test and see if it seems to work!

[linux-cultist]

Im closing this but feel free to reopen if it doesnt solve the issue. :+1:

[ndaman]

Sorry, I thought I had left a reply yesterday but I must have forgotten to submit it. Thanks for the update! It seems the python provider is not being set to the correct path. I get a nice message saying VenvSelect: Activated 'C:\Users\ndama\mambaforge\envs\pickle\python.exe' showing the correct path to python, but :checkhealth reports:

Python 3 provider (optional) ~
- WARNING No Python executable found that can `import neovim`. Using the first available executable for diagnostics.
- WARNING Could not load Python 3:
  python3 not found in search path or not executable.
  python3.10 not found in search path or not executable.
  python3.9 not found in search path or not executable.
  python3.8 not found in search path or not executable.
  python3.7 not found in search path or not executable.
  python not found in search path or not executable.
  - ADVICE:
    - See :help |provider-python| for more information.
    - You may disable this provider (and warning) by adding `let g:loaded_python3_provider = 0` to your init.vim
- Executable: Not found

Python virtualenv ~
- WARNING $VIRTUAL_ENV is set to: C:\Users\ndama\mambaforge\envs\pickle
  But no Python executables found in the virtualenv /Scripts directory.
  So invoking Python may lead to unexpected results.

[linux-cultist]

If VenvSelect shows that message with "activated", it has checked on disk and found a python there and put it first in the path (activated it). Thats also why your $VIRTUAL_ENV is set to the correct parent directory.

I can only assume that neovim also thinks there should be a Scripts directory on windows and for you its not.... hence the warnings here maybe.

If you select a venv with VenvSelect, then open a terminal from inside neovim (:term command) and run "echo $PATH", do you have the virtual env first in your PATH?

[ndaman]

Thanks, yes the PATH variable appears to be set correctly. From that terminal it seems that Windows still finds the wrong python, from a directory which is not even in the PATH variable. I'll do some digging to see how windows decides which python executable to use.

[ndaman]

I found the problem! Windows has an alias for an executable named python.exe, disabling that alias allows path to work correctly, so anyone else like me might find this page useful: https://stackoverflow.com/questions/57485491/python-python3-executes-in-command-prompt-but-does-not-run-correctly/65520328#65520328.

[linux-cultist]

Oh very good that you found that. :)

Then we can consider this issue solved then!