Skip to content

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

@Congee

Description

@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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions