Hi, This is an old bug about Lua and search path.
<http://issues.guix.gnu.org/issue/25425> It is still unsolved: --8<---------------cut here---------------start------------->8--- $ guix environment -C --ad-hoc lua lua-lpeg -- lua Lua 5.3.5 Copyright (C) 1994-2018 Lua.org, PUC-Rio > require('lpeg') stdin:1: module 'lpeg' not found: no field package.preload['lpeg'] no file '/usr/local/share/lua/5.3/lpeg.lua' no file '/usr/local/share/lua/5.3/lpeg/init.lua' no file '/usr/local/lib/lua/5.3/lpeg.lua' no file '/usr/local/lib/lua/5.3/lpeg/init.lua' no file './lpeg.lua' no file './lpeg/init.lua' no file '/usr/local/lib/lua/5.3/lpeg.so' no file '/usr/local/lib/lua/5.3/loadall.so' no file './lpeg.so' stack traceback: [C]: in function 'require' stdin:1: in main chunk [C]: in ? > --8<---------------cut here---------------end--------------->8--- --8<---------------cut here---------------start------------->8--- $ guix environment -C --ad-hoc lua lua-lpeg [env]$ export LUA_PATH="$GUIX_ENVIRONMENT/share/lua/5.3/?.lua;$GUIX_ENVIRONMENT/share/lua/5.3/?/?.lua" [env]$ export LUA_CPATH="$GUIX_ENVIRONMENT/lib/lua/5.3/?.so;$GUIX_ENVIRONMENT/lib/lua/5.3/?/?.so" [env]$ lua Lua 5.3.5 Copyright (C) 1994-2018 Lua.org, PUC-Rio > require('lpeg') table: 0x23fd510 > --8<---------------cut here---------------end--------------->8--- On Sun, 22 Jan 2017 at 23:34, Ricardo Wurmus <[email protected]> wrote: > Ludovic Courtès <[email protected]> writes: >> Ricardo Wurmus <[email protected]> skribis: >>> Ludovic Courtès <[email protected]> writes: >>> >>>> I think this should work: >>>> >>>> (search-path-specification >>>> (variable "LUA_PATH") >>>> (separator ";") >>>> (files '("share/lua/5.3")) >>>> (file-pattern "\\.lua$") >>>> (file-type 'regular)) >>> >>> I tried this very same thing but it doesn’t work because Lua expects >>> placeholders (“?”) in the search paths. The placeholders are replaced >>> with the actual package names. If the actual file name does not exist >>> it will try the next pattern. If the file *does* exist – which *will* be >>> the case for any of the files on LUA_PATH that have been generated by >>> the search-path-specification — Lua will try to load the package from >>> that path. >>> >>> This will fail because a search for the “lpeg” module would be satisfied >>> by the file “re.lua”, because that’s the first valid file on the >>> LUA_PATH. “re.lua” requires “lpeg” itself, so another lookup is >>> performed, which will again result in “re.lua” to be loaded… >>> >>> AIUI we must generate a value for LUA_PATH that keeps the placeholders >>> intact. >> >> So are you saying that it’s important for the question marks to remain >> intact? > > Yes, that seems to be the case. > >> This sounds terrible. I’m not sure how to address it, and I don’t feel >> like stretching the search path mechanism this much. >> >> Thoughts? > > I agree. It’s a really odd special case. On the other hand, not > extending the search path mechanism would mean that we have to find > other ways to fix “guix environment”, build phases, and profiles when > Lua packages are involved. > > Build phases are easy to fix (by using a procedure that sets the > appropriate environment variables depending on the build inputs), but I > don’t know how to make profiles behave the way they should. Maybe it > would be fine to set a single value for LUA_PATH (and LUA_CPATH) that > assumes a single prefix (the profile path) and contains the necessary > placeholders. Is it fixable? All the best, simon
