From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ricardo Wurmus Subject: bug#25425: cannot express search path Date: Sun, 22 Jan 2017 23:34:00 +0100 Message-ID: <874m0q2087.fsf@elephly.net> References: <87shoo7dgx.fsf@mdc-berlin.de> <87r34879o1.fsf@elephly.net> <87bmvc2vjn.fsf@gnu.org> <87lgug72vc.fsf@elephly.net> <87d1feep2q.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:43196) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cVQj4-0003vg-0Q for bug-guix@gnu.org; Sun, 22 Jan 2017 17:35:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cVQj0-0005V4-Un for bug-guix@gnu.org; Sun, 22 Jan 2017 17:35:06 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:40359) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cVQj0-0005Uw-R4 for bug-guix@gnu.org; Sun, 22 Jan 2017 17:35:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cVQj0-0000Jc-LU for bug-guix@gnu.org; Sun, 22 Jan 2017 17:35:02 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-reply-to: <87d1feep2q.fsf@gnu.org> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 25425@debbugs.gnu.org Ludovic Courtès writes: > Hello! > > Ricardo Wurmus skribis: > >> Ludovic Courtès 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. -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net