Page 1 of 1

[SOLVED] require can't read files from LUA_PATH when installed via snap

Posted: Wed May 15, 2019 7:33 pm
by messersm
Hi everyone,

I hope, this question wasn't answered before - I couldn't find relevant information in the forums or the wiki.

I'm new to Löve (using version 11.1) and are trying to load a library ("bump"), which I installed with luarocks (on Ubuntu 18.04). The luarocks path was added to ~/.profile, so every application runs with the specific path. I understand, that it is recommended to copy all required libraries into the game path (especially for distributing), but Löve gives me an error message, which is simply wrong:


Code: Select all

local bump = require "bump"

Code: Select all

Error: main.lua:1: module 'bump' not found:
	no field package.preload['bump']
	no 'bump' in LOVE game directories.
	no file 'bump' in LOVE paths.
	no file '/home/<username>/.luarocks/share/lua/5.2/bump.lua'
	no file '/home/<username>/.luarocks/share/lua/5.2/bump/init.lua'
	no file '/usr/local/share/lua/5.2/bump.lua'
	no file '/usr/local/share/lua/5.2/bump/init.lua'
	no file '/usr/local/lib/lua/5.2/bump.lua'
	no file '/usr/local/lib/lua/5.2/bump/init.lua'
	no file '/usr/share/lua/5.2/bump.lua'
	no file '/usr/share/lua/5.2/bump/init.lua'
	no file './bump.lua'
	no file '/home/<username>/.luarocks/lib/lua/5.2/'
	no file '/usr/local/lib/lua/5.2/'
	no file '/usr/lib/x86_64-linux-gnu/lua/5.2/'
	no file '/usr/lib/lua/5.2/'
	no file '/usr/local/lib/lua/5.2/'
	no file './'
stack traceback:
	[string "boot.lua"]:637: in function <[string "boot.lua"]:633>
	[C]: in function 'require'
	main.lua:1: in main chunk
	[C]: in function 'require'
	[string "boot.lua"]:475: in function <[string "boot.lua"]:311>
	[C]: in function 'xpcall'
	[string "boot.lua"]:645: in function <[string "boot.lua"]:639>
	[C]: in function 'xpcall'
Do note, that require searches in "/usr/local/share/lua/5.2". The thing is, the file is right there:

Code: Select all

<username>@<hostname>:~$ file /usr/local/share/lua/5.2/bump.lua 
/usr/local/share/lua/5.2/bump.lua: UTF-8 Unicode text
Why doesn't require find it?

Re: Löve, require and LUA_PATH

Posted: Thu May 16, 2019 12:42 am
by pgimeno
Hm, maybe you can strace love to see what's happening when trying to open the file? You can use this to filter out the output: strace -f -e trace=open love <your_project_dir>

Incidentally, LÖVE does not use Lua 5.2 (unless you compiled it from source and explicitly enabled it, which I'm not sure is possible).

Re: Löve, require and LUA_PATH

Posted: Thu May 16, 2019 5:22 am
by raidho36
But it's looking for bump.lua in the 5.2 folders. It's probably installed into 5.3 folder.

Anyway, you should always carry all of your dependencies in the game folder, except things like drivers and C runtime libraries. Your game will depend on very specific version of every library being used, and host OS will not provide them.

Re: Löve, require and LUA_PATH

Posted: Thu May 16, 2019 8:27 am
by messersm
Got it: Thanks @pgimeno for the strace idea. It showed, that Löve actually can't read the file (Permission denied), even when running as root. This is due to the fact, that I installed Löve using snap and the Löve snap being very restrictive. The solution would be, to connect the Löve snap "system-files" plug, but the current Löve snap doesn't provide this plug. That way, this program can never access files outside of the snap and home directory. This is a common problem with snap applications.

I'll suggest to the snap maintainer that the Löve snap could have a system-files plug, so that the user can connect it, if wanted or that the snap uses classic confinement.

The solution to my problem is to install Löve in another way, since there is no way to change an installed snap other than repackaging (at least I found none) and snap also ignores the "--classic" flag for strictly confined apps. I'm using the Löve PPA now and everything works as expected:

Code: Select all

$ sudo snap remove love2d
$ sudo add-apt-repository ppa:bartbes/love-stable
$ sudo apt-get update
$ sudo apt-get install love
The executable is then called love instead of love2d.

Supplement: The Lua version of love was not the problem. I tested this by resetting the LUA_PATH and copying the bump library to /usr/local/share/lua/5.1/bump.lua

I'll also update the topic title to mark it as solved and better describe the problem.

See also:
- ... ap-usage#3

Re: [SOLVED] require can't read files from LUA_PATH when installed via snap

Posted: Thu May 16, 2019 3:04 pm
by pgimeno
My suggestion for the future would be to install via downloading the file directly, or cloning the repository, rather than via LuaRocks, and then copying bump.lua into your project's folder. That way, the file will be included in your project in case you distribute it.

I don't think it's frequent enough for any LÖVE application to require access to system files. The only case where I think it's useful is for writing applications just for yourself, where you just use your system-wide resources; but if you plan to distribute them, it's always best to explicitly copy them into your project's folder, so that you don't forget to package anything when the time to ship it comes.

The downside is that you don't get those files automatically updated (unless they are symbolic links or hard links, which is also a possibility), but that can actually be a good thing: you develop your application with a specific version of the libraries; if you update these libraries after the application is already developed and tested, and one of these libraries introduces a change in functionality, or a bug, that can get unnoticed at shipping time, so it's best to stick to the same versions of the libraries during development, unless you need specific bug fixes or features that a newer version has.

One final note. If your version of LÖVE is using Lua 5.2, I recommend you to change it or to complain to the packagers. LuaJIT is typically at least 5x faster, even if restricted to Lua 5.1, and I'd say it's indispensable for game development. In fact it's the fastest dynamic language existing today, rivalling with C.