Same python_parent_path for all venv managers

[i-d-lytvynenko]

I have both anaconda and poetry installed. Anaconda requires python_parent_dir = '' in config, but then the plugin fails to load poetry virtual environments, as python.exe for those is located in Scripts folder.

[linux-cultist]

Interesting. The idea of running several venv managers with completely different settings didn't really occur to me when designing the plugin. But in theory it should be possible, although needing a restructuring of configuration flags so it's venv manager specific. It's quite a big change... But can think about it.

[linux-cultist]

I have a new version of the plugin that will solve this, since it works in a different way. You basically give it a bunch of fd commands to run and the results show up in the telescope viewer.

You can look in the regexp branch here on github for an example how it works. Its still under development though and very untested on windows in particular. So if you are on windows, I would wait a bit longer until it's getting more production ready. Should be a few more weeks or so.

[linux-cultist]

Now I feel like the windows code in the regexp branch seems to work fine.

Here is an example if you want to try it:

Configuration for lazy.nvim:

return {
  "linux-cultist/venv-selector.nvim",
    dependencies = {
      "neovim/nvim-lspconfig", 
      "mfussenegger/nvim-dap", "mfussenegger/nvim-dap-python", --optional
      { "nvim-telescope/telescope.nvim", branch = "0.1.x", dependencies = { "nvim-lua/plenary.nvim" } },
    },
  lazy = false,
  branch = "regexp", -- This is the regexp branch, use this until its merged with the main branch later
  config = function()
      require("venv-selector").setup()
    end,
    keys = {
      { ",v", "<cmd>VenvSelect<cr>" },
    },
},

The plugin will look in $HOME/anaconda3/envs and $HOME/anaconda3 for anaconda venvs automatically but if you have them in another location, you can create two searches of your own.

If you let me know the locations for you, I can help out with a config that adds your own searches. :)

[linux-cultist]

Closing this for now but comment on it if you want some help to get it working.

[i-d-lytvynenko]

I can confirm that this solves the original issue. However, I'll stick to the main branch with minor local code changes until release, as some commands are still missing

[linux-cultist]

Which commands are you missing? I think it's fairly feature complete now... Or what did you have in mind?

[i-d-lytvynenko]

Looking at your code, I agree that the old VenvSelectCurrent command can be easily replaced using the exposed venv function.

VenvSelectCached is technically not needed anymore, though I'd prefer to have a way to activate cached venvs manually (for example, when dealing with multiple projects at once).

Also the deactivate function is still not implemented, which is a problem with activate_venv_in_terminal = true (only in theory, as I haven't tested this part)

[linux-cultist]

I could add the VenvSelectCached command back so it activates the cached venv on user request also. Didnt realize there could be usecases for this, but I guess there could be. :)

The deactivate function is not (properly) implemented in the old version either. I plan to implement it in a way so the lsp forgets about a venv being activated, and all paths that were set will also be removed. Just need to figure out how to make the lsp forget the activation. I dont want to have to restart it since then all LSP projects are affected, including non-python ones.