search

wbthomason / packer.nvim

A use-package inspired plugin manager for Neovim. Uses native packages, supports Luarocks dependencies, written in Lua, allows for expressive config
MIT License
7.89k stars 264 forks source link

Allow for system package luarocks #175

Open wbthomason opened 3 years ago

wbthomason commented 3 years ago

Add an option to allow the luarocks functionality to use a system-level luarocks package, if installed, rather than re-installing luarocks and luaJIT via hererocks.

matu3ba commented 3 years ago

This will break sandboxing, ie with firejail, as luarocks does not conform to XDGBDS.

wbthomason commented 3 years ago

@matu3ba: could you say more? This would not allow the luarocks module to install to or uninstall from system-level rock trees, but just avoid installs if a rock already exists. Does that still break sandboxing in an undesirable way?

matu3ba commented 3 years ago

@matu3ba: could you say more? This would not allow the luarocks module to install to or uninstall from system-level rock trees, but just avoid installs if a rock already exists. Does that still break sandboxing in an undesirable way?

Sorry for not explaining properly. The behavior occurs for firejail, which is the easiest to use (and fairly complete) sandboxing solution for Linux desktop programs (I tested luarocks).

What happens is that luarocks downloads the manifest to $HOME and errors out in a unexpected way (and very unclear way) about not finding proper paths, because default sandboxing only allows data access to often necessary paths of applications like .config, .local. Access to "unknown paths" in $HOME like .luarocks is forbidden on default, unless there is a profile for the application.

When do you plan to implement this?

wbthomason commented 3 years ago

I certainly won't be implementing this before March, and I'd characterize it as not very high priority.