aboutsummaryrefslogtreecommitdiff
path: root/runtime/lua/provider/python
Commit message (Collapse)AuthorAge
* refactor!: remove `nvim` and `provider` module for checkhealthdundargoc2024-05-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.*`.
* refactor: remove fn_booldundargoc2024-04-06
| | | | | It's better to use vim.fn directly instead of creating minor abstractions like fn_bool.
* refactor: create function for deferred loadingdundargoc2024-02-03
| | | | | | | | | | | | | | | | The benefit of this is that users only pay for what they use. If e.g. only `vim.lsp.buf_get_clients()` is called then they don't need to load all modules under `vim.lsp` which could lead to significant startuptime saving. Also `vim.lsp.module` is a bit nicer to user compared to `require("vim.lsp.module")`. This isn't used for some nested modules such as `filetype` as it breaks tests with error messages such as "attempt to index field 'detect'". It's not entirely certain the reason for this, but it is likely it is due to filetype being precompiled which would imply deferred loading isn't needed for performance reasons.
* fix(health): "attempt to concatenate nil"Justin M. Keyes2024-01-28
| | | | | | | | | | | | | Problem: If `neovim` module is not installed, python and ruby healthchecks fail: - ERROR Failed to run healthcheck for "provider.python" plugin. Exception: .../runtime/lua/provider/python/health.lua:348: attempt to concatenate local 'pyname' (a nil value) - ERROR Failed to run healthcheck for "provider.ruby" plugin. Exception: .../runtime/lua/provider/ruby/health.lua:25: attempt to index local 'host' (a nil value) Solution: Check for non-nil.
* refactor: rewrite python provider in luadundargoc2024-01-22
|
* fix(health): improve python executable check error handling (#26954)Barrett Ruth2024-01-10
| | | Credit to @wookayin for the fix.
* fix(health): correctly expand and resolve PYENV_ROOT (#26953)Barrett Ruth2024-01-10
|
* refactor(health): refactor provider healthchecksGregory Anders2024-01-01
* Prefer pure Lua functions over vim.fn * Split up provider healthchecks into separate modules to help manage complexity