Commit Graph

21 Commits

Author SHA1 Message Date
Michael Henry
5f8d4a248a feat(provider): detect venv python via "pynvim-python" tool #35273
Problem:
Detection of the pynvim module is currently done by finding the first
Python interpreter in the `PATH` and checking if it can import pynvim.
This has several problems:
- Activation of an unrelated Python virtual environment will break
  automatic detection, unless pynvim is also installed in that
  environment.
- Installing pynvim to the expected location is difficult. User
  installation into the system-wide or user-wide Python site area is now
  deprecated.  On Ubuntu 24.04 with Python 3.12, for example, the
  command `pip install --user pynvim` now fails with the error message
  `error: externally-managed-environment`.
- Users may create a dedicated virtual environment in which to install
  pynvim, but Nvim won't detect it; instead, they must either activate
  it before launching Nvim (which interferes with the user of other
  virtual environments) or else hard-code the variable
  `g:python3_host_prog` in their `init.vim` to the path of the correct
  Python interpreter.  Neither option is desirable.

Solution:
Expose pynvim's Python interpreter on the `PATH` under the
name `pynvim-python`.  Typical user-flow:

1. User installs either uv or pipx.
2. User installs pynvim via:
   ```
   uv tool install --upgrade pynvim
   # Or:
   pipx install --upgrade pynvim
   ```

With corresponding changes in pynvim https://github.com/neovim/pynvim/issues/593
the above user-flow is all that's needed for Nvim to detect the
installed location of pynvim, even if an unrelated Python virtual
environments is activated.  It uses standard Python tooling to automate
the necessary creation of a Python virtual environment for pyenv and the
publication of `pynvim-python` to a directory on `PATH`.
2025-08-16 14:48:08 -07:00
Yochem van Rosmalen
35af766de6 refactor(lua): use vim.system #34707 2025-07-23 20:03:30 -07:00
zeertzjq
e87d2ae383 fix(checkhealth): check outdated pynvim version properly #33175
Fixes #33174, a regression from #22962.
2025-03-30 07:02:59 -07:00
Justin M. Keyes
5f9f5bc04d fix(checkhealth): check g:loaded_xx_provider for all providers #33168 2025-03-29 13:35:06 -07:00
v1nh1shungry
ade58885c4 fix(provider)!: drop Python 3.7, 3.8 support #33088
Problem: #33022 didn't update `min_version` to 3.9, therefore Python 3.7
and 3.8 are still available.

Solution: Update `min_version` to 3.9.
2025-03-28 04:49:10 -07:00
Eisuke Kawashima
4d9a1b9852 feat(provider/python)!: add python 3.13, drop 3.7 and 3.8 (EOL) #33022
https://devguide.python.org/versions/

Co-authored-by: Eisuke Kawashima <e-kwsm@users.noreply.github.com>
2025-03-22 07:20:46 -07:00
Lewis Russell
6aa42e8f92 fix: resolve all remaining LuaLS diagnostics 2025-01-27 16:37:50 +00:00
dundargoc
3a86b60032 docs: misc
Co-authored-by: David Pedersen <limero@me.com>
Co-authored-by: Gregory Anders <greg@gpanders.com>
Co-authored-by: Leo Schlosser <Leo.Schlosser@Student.HTW-Berlin.de>
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
2024-10-23 14:13:42 +02:00
Justin M. Keyes
47e6b2233f fix(vim.fs): dirname() returns "." on mingw/msys2 #30480
Problem:
`vim.fs.dirname([[C:\User\XXX\AppData\Local]])` returns "." on
mingw/msys2.

Solution:
- Check for "mingw" when deciding `iswin`.
- Use `has("win32")` where possible, it works in "fast" contexts since
  b02eeb6a72.
2024-09-23 06:05:58 -07:00
Abao Zhang
b4b4cf46a7 fix(health): fix pyenv root and python exepath detect issue
Fix the following two issues:

- pyenv root detection issue

When `PYENV_ROOT` environment variable is not set, neovim will detect
pyenv's root via `pyenv root` command, but which will be always fail
because `vim.fn.system()` returns result with additional `\n`. Using
`vim.system` instead prevents this problem. to trim it before check
whether it is exists

- python executable path detection issue

Filter unrelated `python-config` in cases where multiple python versions
are installed, e.g. `python-config`, `python3.10-config`,
`python3.11-config` etc.
2024-07-24 16:21:46 +02:00
Stanislav Asunkin
5b778a64ec fix(health): fix fetching url with python in provider health (#29594) 2024-07-07 16:37:39 +08:00
Ilia Choly
8cbb1f20e5 refactor(lua): use tuple syntax everywhere #29111 2024-06-04 06:06:02 -07:00
dundargoc
6e8a728e3d refactor: fix luals type warnings 2024-05-27 20:48:46 +02:00
dundargoc
520c2657bb refactor: move provider-related to where they are used 2024-05-25 20:13:17 +02:00
dundargoc
1a2e6ebc59 refactor: replace deprecated vim.loop with vim.uv 2024-05-24 16:41:02 +02:00
dundargoc
01b4da65c2 fix: merge all provider healthchecks into a single health.lua
This will help manage the overly granular checkhealth completion to go
from

```
vim.health
vim.lsp
vim.provider.clipboard
vim.provider.node
vim.provider.perl
vim.provider.python
vim.provider.ruby
vim.treesitter
```

to

```
vim.health
vim.lsp
vim.provider
vim.treesitter
```
2024-05-22 21:34:49 +02:00
dundargoc
e8f7025de1 docs: move vim.health documentation to lua.txt
`vim.health` is not a "plugin" but part of our Lua API and the
documentation should reflect that. This also helps make the
documentation maintenance easier as it is now generated.
2024-05-22 20:15:17 +02:00
dundargoc
0f4f7d32ce refactor!: remove nvim and provider module for checkhealth
The namespacing for healthchecks for neovim modules is inconsistent and
confusing. The completion for `:checkhealth` with `--clean` gives

```
nvim
provider.clipboard
provider.node
provider.perl
provider.python
provider.ruby
vim.lsp
vim.treesitter
```

There are now three top-level module names for nvim: `nvim`, `provider`
and `vim` with no signs of stopping. The `nvim` name is especially
confusing as it does not contain all neovim checkhealths, which makes it
almost a decoy healthcheck.

The confusion only worsens if you add plugins to the mix:

```
lazy
mason
nvim
nvim-treesitter
provider.clipboard
provider.node
provider.perl
provider.python
provider.ruby
telescope
vim.lsp
vim.treesitter
```

Another problem with the current approach is that it's not easy to run
nvim-only healthchecks since they don't share the same namespace. The
current approach would be to run `:che nvim vim.* provider.*` and would
also require the user to know these are the neovim modules.

Instead, use this alternative structure:

```
vim.health
vim.lsp
vim.provider.clipboard
vim.provider.node
vim.provider.perl
vim.provider.python
vim.provider.ruby
vim.treesitter
```

and

```
lazy
mason
nvim-treesitter
telescope
vim.health
vim.lsp
vim.provider.clipboard
vim.provider.node
vim.provider.perl
vim.provider.python
vim.provider.ruby
vim.treesitter
```

Now, the entries are properly sorted and running nvim-only healthchecks
requires running only `:che vim.*`.
2024-05-19 11:46:34 +02:00
dundargoc
b280d57db9 refactor: rewrite ruby provider in lua 2024-01-24 19:26:53 +01:00
dundargoc
576db141be refactor: rewrite perl provider in lua 2024-01-24 11:55:28 +01:00
dundargoc
eb5d15e383 refactor: rewrite python provider in lua 2024-01-22 22:36:40 +01:00