Closed lvignoli closed 2 months ago
Should be very easy to add I think. We could just look at default dir and let the user specify another dir if needed, just like we do with PipEnv and Poetry already.
Im on vacation now for 2 weeks though, enjoying Italy! :) But when im back I could add support for it.
Great news! Marvelous country for vacations, I was there 10 days ago haha 😃 Enjoy 🇮🇹!
Yeah its the best. Been there 2 times before also, and just love the food and the atmosphere. :)
Ok I have added support for Hatch in the latest commit, but you may have to change the default paths if your hatch virtual environments dont show up. :)
The default paths are:
Linux = "~/.local/share/hatch/env/virtual",
Darwin = "~/Library/Application Support/hatch/env/virtual",
Windows_NT = "%USERPROFILE%\\AppData\\Local\\hatch\\env\\virtual",
If you want to change the default hatch path, use the hatch_path
option in your settings, like this:
require("venv-selector").setup({
hatch_path = "your_path_to_the_virtual_folder_here"
})
You should see something like this (with hatch venvs being included):
If this works for you, I will update the README that Hatch is supported now.
Im closing this but reopen if Hatch environments still are not found. It works on my system but you never know.
Hi @linux-cultist, thank for your work!
I was in holidays. Coming back today, it does not work out of the box for me on macOS 13.4. I think the error simply comes from not escaping the space in the path, since when I refresh with C-r
I get:
[fd error]: Search path '/Users/me/Library/Applications` is not a directory.
[fd error]: Search path 'Support/hatch/env/virtual/*/*` is not a directory.
Ah yes, looks likely. I will see what I can do about that. :)
Updating for 27c502e (which has #39 merged), I still experience the same issue and error about the path. I guess it's not the proper way to escape …
Maybe using [[ ]]
syntax is a fix?
I dont know, can experiment a bit after work today and see what is needed. But should be easy with the right format. :)
On Wed, Jul 12, 2023, at 11:59, Louis Vignoli wrote:
Maybe using
[[ ]]
syntax is a fix?— Reply to this email directly, view it on GitHub https://github.com/linux-cultist/venv-selector.nvim/issues/33#issuecomment-1632211044, or unsubscribe https://github.com/notifications/unsubscribe-auth/A6ENW5D2RJXA6QCNK2X5PSLXPZYOVANCNFSM6AAAAAAZM3G43E. You are receiving this because you modified the open/close state.Message ID: @.***>
If you want to experiment yourself, you can set hatch_path as an option to the setup function, and try to escape it. It will override the default path you see in the code.
I played around a bit tonight and I can escape the space so it shows the venv in the telegram viewer, but need to make more changes for it to be able to be activated and part of the system path.
Will take a bit more time to get it sorted. In the mean time, you can always set a different hatch path without space and tell VenvSelect to use it. :)
Spaces in paths have always been a pain for computers :)
That's great news! I tried 5mins and was unable to do so.
Yes, that's a nice fix in the meantime for sure. Thanks for trying to be feature complete in the fractured ecosystem of python project managers 😀
This is still on my todo list... It's been so many other things I wanted to explore lately. But I will find some time soon. :)
This works for me, have you added support for spaces already?
require('venv-selector').setup { hatch_path = vim.env.HOME .. "/Library/Application Support/hatch/env/virtual/"
No it got lost in so many other things. I don't think it's hard to implement, just need to sit down and look at the code sometime.
As you may have noticed, there is a new rewritten version of the plugin in the regexp
branch. :)
The old code was simply too difficult to maintain since it had evolved over the last year into supporting so many venv managers, each one needing specific changes to the core of the plugin and sometimes many conditional statements to try and guess what the user wanted.
The rewrite is much cleaner and you can add searches yourself without changing the plugin code. But it also has all the default searches from the original, so it should find the same things (and be more accurate).
The reason im writing you is that it also supports spaces in paths by default. So you should try it and see what you think. :)
It doesnt use any of the old config so that can be thrown away. The new config is a lot simpler.
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>" },
},
},
You can read the README in the regexp
branch to see how you add new searches, but there is a good chance the default ones will pick up your venvs without any config on your part.
Closing this since it should work fine in the regexp branch. Please try it. :)
Hatch is popular python project manager that takes care of virtual environments as well.
Could vent-selector also search into the default location for hatch?
Any type of environment that is not explicitly defined will default to <DATA_DIR>/env/<ENV_TYPE>.
(see there)