Hi,
This is an old bug about Lua and search path.
It is still unsolved:
Toggle snippet (21 lines)
$ 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 ?
>
Toggle snippet (11 lines)
$ 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
>
On Sun, 22 Jan 2017 at 23:34, Ricardo Wurmus <rekado@elephly.net> wrote:
Toggle quote (51 lines)
> Ludovic Courtès <ludo@gnu.org> writes:
>> Ricardo Wurmus <rekado@elephly.net> skribis:
>>> Ludovic Courtès <ludo@gnu.org> 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
