speed up check for pynvim

[arcxio]

speed up check for pynvim

[bfredl]

rm ~/.config/nvim/init.lua

Hmm, python provider is supposed to only be loaded on demand, not with (really) empty config. You might have some plugin in your runtimepath which checks has("python3") on startup. This can be disabled with nvim --clean +q

[bfredl]

but I still think it's worth fixing the performance issue with calling python to check if pynvim is available so that it lowers startup time when using python plugins anyway.

such a check would just be an approximation. the only way to check if python can import a package is to invoke python and try to import the package. any external reimplementation of importlib/virtualenv/etc/etc is going to be out of date pretty much instantly given the frequent changes to the python tooling ecosystem.

Instead, a well-behaved python plugin should defer to check has("python3") until it actually needs to know that, not haphazardly at neovim startup.

[arcxio]

You might have some plugin in your runtimepath which checks has("python3") on startup.

you're right, it seems that the AUR package neovim-nightly-bin which I use includes a bunch of vim plugins to runtimepath, including black.vim which triggers python provider, I may suggest them to fix it there. but I still think it's worth fixing the performance issue with calling python to check if pynvim is available so that it lowers startup time when using python plugins anyway.

[justinmk]

Has been discussed many time before. The search doesn't happen unless your config triggers it.

[clason]

it seems that the AUR package neovim-nightly-bin which I use includes a bunch of vim plugins to runtimepath

Wow. They should not do that. Please complain to them very loudly.

[arcxio]

The search doesn't happen unless your config triggers it

the issue is not really that the search happens, the issue is that the search is much slower that it has to be

[clason]

The search is the way it is for a reason, though: robustness (venv, pip, etc.).