E605: Exception not caught: Unable to determine basepath from script (during incpy#LoadPlugin)

[arizvisa]

On older versions of Neovim, the following exception is raised (and uncaught). This is happening due to the expand("<sfile>:p:h") returning a path other than the plugin base directory. As a result of the wrong path being returned, the function call to incpy#SetupPythonLoader which follows will search the wrong path for the "python" directory and not find it.

Error detected while processing function incpy#LoadPlugin[5]..incpy#SetupPythonLoader:
line   10:
E605: Exception not caught: Unable to determine basepath from script

The logic that triggers this is literally <sfile>->incpy#LoadPlugin->incpy#SetupPythonLoader(..., expand("<sfile>:p:h")). If you execute expand("<sfile>:p:h") from the scope of the script, it returns the correct value... but if you do it from inside the incpy#LoadPlugin function, it returns a completely different value. So somehow during the change in scope from calling a function, Neovim botches up its expansion of <sfile>.

This manifests itself on Ubuntu 22.04 where the Neovim version is:

NVIM v0.6.1
Build type: Release
LuaJIT 2.1.0-beta3
Compiled by [email protected]

For the record, the most current version of Neovim (where this issue doesn't exist) is:

NVIM v0.10.2
Build type: RelWithDebInfo
LuaJIT 2.1.1720049189
Compilation: /usr/bin/gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -O2 -g -Og -g -flto=auto -fno-fat-lto-objects -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wvla -Wdouble-promotion -Wmissing-noreturn -Wmissing-format-attribute -Wmissing-prototypes -fsigned-char -fstack-protector-strong -Wno-conversion -fno-common -Wno-unused-result -Wimplicit-fallthrough -fdiagnostics-color=auto  -DUNIT_TESTING -DHAVE_UNIBILIUM -D_GNU_SOURCE -DINCLUDE_GENERATED_DECLARATIONS -I/usr/include/luajit-2.1 -I/usr/include -I/builddir/build/BUILD/neovim-0.10.2-build/neovim-0.10.2/redhat-linux-build/src/nvim/auto -I/builddir/build/BUILD/neovim-0.10.2-build/neovim-0.10.2/redhat-linux-build/include -I/builddir/build/BUILD/neovim-0.10.2-build/neovim-0.10.2/redhat-linux-build/cmake.config -I/builddir/build/BUILD/neovim-0.10.2-build/neovim-0.10.2/src 

I looked around in the ticket tracker at https://github.com/neovim/neovim to see if there was a related issue that I could reference, but was unable to find one. This will probably require a bisect to figure out which version (and commits) are affected by this.

[arizvisa]

Apparently commit neovim/neovim@98ab0bb is responsible for fixing this bug. That commit is based on vim/vim@a5d0423 which was merged back in 2020.

I'm unsure if the issue actually exists in vim or not as the line in question was written back in 2014, and I'm unable to compile that version of vim for some reason.