Automatically source venvs

[theevocater]

When in a python based project (eg, has a venv or .venv) automatically
source it before running the lsp etc.

[Copilot]

Pull request overview

This PR adds automatic Python virtualenv activation to the Neovim configuration. When Neovim starts in a directory containing a Python virtual environment (venv or .venv), it automatically activates that environment by setting the VIRTUAL_ENV and PATH environment variables. This ensures that Python LSP servers and tools use the correct virtual environment without manual activation.

Changes:

• Added a activate_virtualenv() function that checks for venv/.venv directories in the current working directory
• Added a VimEnter autocmd to trigger virtualenv activation when Neovim starts

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The virtualenv activation only runs on VimEnter, which means if the user changes directories (e.g., with :cd or :tcd), the virtualenv won't be updated for the new directory. Consider also adding a DirChanged autocmd to re-run the activation when the working directory changes, ensuring the correct virtualenv is activated when navigating between different Python projects.

Suggested change

	vim.api.nvim_create_autocmd("VimEnter", {
	vim.api.nvim_create_autocmd({ "VimEnter", "DirChanged" }, {

[Copilot]

The autocmd is not assigned to an augroup, which is inconsistent with other autocmds in this file (e.g., line 661 uses vim.api.nvim_create_augroup). Consider creating an augroup with clear = true to ensure the autocmd doesn't get duplicated if the config is reloaded.

Suggested change

	vim.api.nvim_create_autocmd("VimEnter", {
	local venv_augroup = vim.api.nvim_create_augroup("PythonVirtualenvAutoActivation", { clear = true })
	vim.api.nvim_create_autocmd("VimEnter", {
	group = venv_augroup,

[Copilot]

The code uses Unix-specific path separators ("/bin/python"). While this may be intentional if the configuration is only used on Unix-like systems, consider using vim.fn.has('win32') to check the platform and use appropriate path separators, or use path manipulation functions that handle this automatically. This would make the configuration more portable.

Suggested change

	for _, venv_name in ipairs(venv_paths) do
	local venv_path = cwd .. "/" .. venv_name
	local python_path = venv_path .. "/bin/python"
	if vim.fn.isdirectory(venv_path) == 1 and vim.fn.executable(python_path) == 1 then
	vim.env.VIRTUAL_ENV = venv_path
	vim.env.PATH = venv_path .. "/bin:" .. vim.env.PATH
	-- Determine platform-specific settings
	local is_windows = vim.fn.has("win32") == 1 or vim.fn.has("win64") == 1
	local path_sep = is_windows and "\\" or "/"
	local python_dir = is_windows and "Scripts" or "bin"
	local python_exe = is_windows and "python.exe" or "python"
	local path_list_sep = is_windows and ";" or ":"
	for _, venv_name in ipairs(venv_paths) do
	local venv_path = cwd .. path_sep .. venv_name
	local python_path = venv_path .. path_sep .. python_dir .. path_sep .. python_exe
	if vim.fn.isdirectory(venv_path) == 1 and vim.fn.executable(python_path) == 1 then
	vim.env.VIRTUAL_ENV = venv_path
	vim.env.PATH = venv_path .. path_sep .. python_dir .. path_list_sep .. vim.env.PATH

[Copilot]

The PATH modification prepends the venv bin directory without checking if it's already in PATH. If the function is called multiple times (e.g., if a DirChanged autocmd is added), this could lead to duplicate PATH entries. Consider checking if the path is already present before prepending, or removing the old venv path before adding the new one.