Packer.nvim: Latest neovim master no longer requires (nor tolerates) update_package_paths

[clason]

Neovim just merged https://github.com/neovim/neovim/pull/13119, which means start (Lua) packages are available already in init.vim without requiring packadd! or vim._update_package_paths() -- in fact, the latter is now an error in the compiled lazy loader code.

Removing https://github.com/wbthomason/packer.nvim/blob/2aba863c46e786eb05198040773c593851d773d0/lua/packer/compile.lua#L445 fixes this. (I believe these calls are not required anyway on current master; I don't know if it makes sense to keep code for older 0.5.0 nightlies or even 0.4.x?)

[wbthomason]

Ah, excellent news! packer doesn't work with 0.4.x at all for other reasons (#1). Unless there's an easy way to check if a Neovim version has that PR merged, I think I'll opt to not keep the code for older versions around.

[madskjeldgaard]

Hi should the quickstart code in this readme maybe be updated as well to remove the update package paths line? Thanks!

[clason]

The Readme is still correct, since it explicitly says the line is only required on older commits :)

But probably yes, just to be safe...

(But then maybe mention that neovim needs to be newer than https://github.com/neovim/neovim/commit/bab5b2fbdae26b5ab898564c429b54f01bbd04b2 (Nov 2, 2020) to support packer.)

[madskjeldgaard]

Cool! I was personally a bit confused by it with this update but that's
just my 2 cents. Thanks!

On 03-11-2020, Christian Clason wrote:

The Readme is still correct, since it explicitly says the line is only required on older commits :)

But probably yes, just to be safe...

--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/wbthomason/packer.nvim/issues/81#issuecomment-720980764

[p00f]

hey why is my lua package.path not synced withrtp now?
lua package.path:

./?.lua;/usr/share/luajit-2.0.5/?.lua;/usr/local/share/lua/5.1/?.lua;/usr/local/share/lua/5.1/?/init.lua;/usr/share/lua/5.1/?.lua;/usr/share/lua/5.1/?/init.lua

nvim rtp: https://del.dog/ghuhithily

[clason]

Wrong repo for this -- you need to ask @bfredl on the neovim repo. If you open an issue, please add a lot more detail to allow reproducing.

hey why is my lua package.path not synced withrtp now?
lua package.path:

./?.lua;/usr/share/luajit-2.0.5/?.lua;/usr/local/share/lua/5.1/?.lua;/usr/local/share/lua/5.1/?/init.lua;/usr/share/lua/5.1/?.lua;/usr/share/lua/5.1/?/init.lua

nvim rtp: https://del.dog/ghuhithily

Wrong repo for this -- you need to ask @bfredl on the neovim repo. If you open an issue, please add a lot more detail to allow reproducing.

[bfredl]

It is synced. We just no longer generate a needlessly long concatenated string in order to make it happen.

[Olical]

So a Lua require('foo') will look in the package.path and _then_ the runtimepath?

[bfredl]

I think so. I added the 'rtp' loader last into package.loaders so any explicit package.[c]path will take priority I think (we can of course flip this around if we prefer 'rtp' first).

[Olical]

Ah okay, I relied on the runtimepath / package.path having a full string in them at init.vim time so that I could copy it and swap out lua for fnl to basically translate package.path into fennel.path. I guess I need to find a new way to get the list of directories on the runtimepath. It seems like on my 0.4, at the time my lua runs, I can see the full runtimepath but a user on the latest Neovim using packer doesn't have a populated runtimepath at the same point of startup.

[bfredl]

@Olical ahyes, sorry for breaking your usecase :sweat_smile: . The new api nvim_get_runtime_file _should_ be simpler for aniseed and such frameworks in the long run, but supporting both 0.4 and master (0.5) at the same time will require a big ugly if-statement unfortunately. (our docs are a bit messy, but when/if I get the time I will do the PR at aniseed myself )

[Olical]

@bfredl No worries, just want to find what the future solution will look like, I'm happy to put in some branches to support the stable release and nightly. I live in stable land but some of my intrepid users are running off of master, I want to make sure I'm future proofed. I'll have a look at the new API, thanks for the heads up!

[bfredl]

actually nvim_get_runtime_file is not fully ready yet, you can only query files (as in octet streams) and not subdirectories as such. At least pynvim is gonna need directories, and aniseed might prefer getting a list of all fnl/ dirs, instead of looking up every nvim_get_runtime_file("fnl/myplugin/mymod.fnl") separately, maybe?

[wbthomason]

@bfredl is there a PR or issue to track for nvim_get_runtime_file?