Packer.nvim: Luarocks clean tries to remove system installed rocks

[akinsho]

I recently tried out the luarocks integration which is amazing 🚀 , a brave new world for nvim plugins with that 🤩 .

I just wanted to point out/mention that it seems that the luarocks clean command which I'm guessing is run as part PackerClean if you have any rocks installed attempts to remove other system rocks that were installed outside of nvim i.e. I downloaded luarocks manually awhile ago and installed the luaformatter rock which packer now attempts to clean every time I run packer clean.

[wbthomason]

Yikes, that's a bad error. Thanks for the report! I don't have any system-installed rocks, so I was unaware that this was happening.

I admit I'm surprised by the issue - the whole point of using hererocks was supposed to be to isolate luarocks operations to just the set of rocks packer is managing. I'll have to look into why that's not happening.

[akinsho]

Well it doesn't seem to be able to remove them successfully so it hasn't caused any issues just the failed message whenever I run clean.

[wbthomason]

Could you remind me what OS you're on? I can't seem to reproduce this on my system; packer only seems to see the rocks it has managed.

[akinsho]

@wbthomason I'm on Ubuntu 20.10, I installed luarocks for lua 5.1 using the docs on the repo. Here's the output of my luarocks list command. luaformatter ended up being installed as user rock rather than a system one, sorry I'd forgotten that detail not sure if that's why it's causing this conflict. Although my system luarocks finds it but not rocks I installled through packer

Rocks installed for Lua 5.1
---------------------------

luaformatter
   scm-1 (installed) - /home/akin/.luarocks/lib/luarocks/rocks-5.1

luarocks
   3.3.1-1 (installed) - /usr/local/lib/luarocks/rocks-5.1

[wbthomason]

Ah - I only had rocks installed for Lua 5.4. Installing something for 5.1 lets me reproduce the bug. I have no idea why it's happening, though.

[wbthomason]

More unfortunately, I think this may be a luarocks bug...

If I do the following manual steps:

1. cd ~/.cache/nvim/packer_hererocks
2. source 2.0.5/bin/activate
3. Run luarocks list - note that luaformatter shows up
4. Run luarocks remove luaformatter - luarocks claims that it "could not find rock 'luaformatter' in ~/.cache/nvim/packer_hererocks/2.0.5"

This implies to me that while luarocks remove is looking in the right place (i.e. restricting itself to packer's rocks, luarocks list has a bug and looks in ~/.luarocks/lib/luarocks/rocks-5.1.

[akinsho]

@wbthomason looking at luarocks -h help there appears to be a --tree and --namespace flag which I haven't looked into at all but sound like maybe they might be a way of pointing lua rocks at a specific place or a specific namespace?

[akinsho]

A bit more from the help docs

   --tree <tree>         Which tree to operate on.
   --local               Use the tree in the user's home directory.
                         To enable it, see '/usr/local/bin/luarocks help path'.

Seems to imply that luarocks can be pointed at a specific tree I just tried this locally using luarocks list --tree local and it doesn't show the same set of rocks

[wbthomason]

Yes, sorry, I just haven't had time since Monday to do significant packer work. I'm planning to see if I can figure out the right tree argument to use once I have a chance.

[nanotee]

I've also been getting warnings from packer saying it can't uninstall some rocks

Applying this patch to line 142 in lua/packer/luarocks.lua seems to fix the bug (I have tested installing and uninstalling a rock and both worked OK)

-    fmt('%s && luarocks %s', activate_hererocks_cmd(hererocks_install_dir), args)
+    fmt([[%s && luarocks --tree='%s' %s]], activate_hererocks_cmd(hererocks_install_dir), hererocks_install_dir, args)

One concern I have is that different shells might treat quoting and variable expansion differently...

[akinsho]

@nanotee that sounds great, would be nice to finally silence the error. Regarding the quote expansion, I'm guessing that this is a general problem that packer faces and has a solution for or not. I wonder if the quoting is necessary or if you can rely on vim's shellescape function here instead?

[wbthomason]

Shoot, sorry - I let this slip through the cracks.

I tried a similar patch to this and found that it silently failed if I did not already have the tree directory in place, then never got around to fixing that issue. I did also use shellescape, which maybe indicates that it causes problems?

[wbthomason]

Ah, I think I figured it out - can't call shellescape off the main loop. Should have a patch pushed shortly. Thanks for the reminder!

[wbthomason]

Should be good to go now; please let me know if you keep encountering it!