require fallback doesn't seem to work
Opened this issue · 8 comments
[11:40:20] Here's an easy repro case for the luvit require problem I'm running into...
[11:40:34] git clone https://github.com/sctb/lumen
[11:40:37] cd lumen
[11:40:46] LUMEN_HOST=luvit bin/lumen
[11:41:17] That will blow up with an error: No such module 'compiler' in ...
[11:41:53] But LUA_PATH is set at that point
[11:43:22] so it unfortunately doesn't seem true that luvit falls back to lua's normal require whenever luvit can't find something
See #858 (comment) for a solution.
See luvit/lit#155
This is still an issue. When Luvit's require falls back to Lua's, the environment of the required file with have Lua's require, not Luvit's.
Simple reproduction:
./main.lua:
print('require', require)
print('_G.require', _G.require)
require('test')./test.lua:
print('test.lua')
print('require', require)
print('_G.require', _G.require)luvit main.lua will print:
require function: 0x00345158 -- this is luvit's require
_G.require function: 0x002f3ee8 -- this is lua's require
test.lua
require function: 0x002f3ee8 -- this is lua's require
_G.require function: 0x002f3ee8 -- this is lua's requireThe 'simple' fix is to move all requires into either libs or deps so that Luvit's require is the one that finds them and Lua's require fallback is never triggered.
When Luvit's require falls back to Lua's, the environment of the required file with have Lua's require, not Luvit's.
Yes, this is by design. Or better stated, we don't guarantee that you keep luvit's require once you enter lua require world. It's a one-way door out.
We could change the design by replacing _G.require with the luvit one and keeping a closure reference to the original require internally. But I think this will break lots of existing code.
The idea is code written for lua's require expects lua's require.
The idea is code written for lua's require expects lua's require.
Right, I guess I'm mostly of the opinion that Luvit's require should work exactly like Lua's require in all instances where Lua's require would normally work, and only diverge in ways that don't break how Lua handles requires. That would be mostly true if #932 was implemented but there are still unresolved things there as well.
Fixing this would almost certainly be a breaking change regardless of how its fixed.
Agreed, maybe we should consider luvit 3.0 at some point. Maybe next time I'm working on a project that uses luvit I can spend more time on it.
But if someone else wants to drive it, I can give advice/opinion.