packer_compiled.vim is sourced too late to use rocks in init.lua

[Congee]

Yo, there. I truly appreciate your effort poured on this amazing plugin 😀 It is life-changing!

This is a follow up of #173 and #196

package.path is not updated to package_path_str defined in packer_compiled.vim until the compiled artifact is sourced. Unfortunately, packer_compiled.vim is put to runtimepath/plugin by default which is loaded after init.lua.

local package_path_str = "/home/congee/.cache/nvim/packer_hererocks/2.1.0-beta3/share/lua/5.1/?.lua;/home/congee/.cache/nvim/packer_hererocks/2.1.0-beta3/share/lua/5.1/?/init.lua;/home/congee/.cache/nvim/packer_hererocks/2.1.0-beta3/lib/luarocks/rocks-5.1/?.lua;/home/congee/.cache/nvim/packer_hererocks/2.1.0-beta3/lib/luarocks/rocks-5.1/?/init.lua"
local install_cpath_pattern = "/home/congee/.cache/nvim/packer_hererocks/2.1.0-beta3/lib/lua/5.1/?.so"
if not string.find(package.path, package_path_str, 1, true) then
  package.path = package.path .. ';' .. package_path_str
end

Therefore, there is no way to use rocks managed by packer if I don't manually source packer_compiled.vim in init.lua. But if I do it, packer_compiled.vim will later be sourced by packer.nvim anyway. Hmmm, sourcing it twice may not be a good idea 😅

I would like to make a feature request to use a global variable in packer_compiled.vim to skip sourcing it if it's sourced already like we usually do in C header files #ifdef _HEADER_H_. Or, packer.nvim may choose to provide a config to disable auto sourcing packer_compiled.vim. Neither are elegant solutions IMHO and I hope there is a better one.

[shadmansaleh]

Packer doesn't source the config but rather since default packer_compiled location is in plugin/ dir (neo)vim sources it.
I think you can use custom init and specify compile_path to somwhere out of plugin/ directory . And source the packer_compiled.vim in your config :). A source guard is a good idea . I think PackerCompile will have to clean it before sourceing it again.

[wbthomason]

@shadmansaleh is correct; we're also working on refactoring packer so that you can load these parts earlier in the startup process (i.e. in init.lua). Currently that's in #331 (which I need to finish and merge), but will require a couple more steps.

The end result will be that you can call some packer function (yet to be named) in your init, it'll set up things like path tweaks and lazy-loaders (without having to regenerate that information) and check if you need to recompile packer_compiled (and do that for you). Sorry to say "it's coming", but I think that's the long-term answer here, with @shadmansaleh's suggestion as a viable workaround.

[Congee]

Closing as this project is dead #1229