Luarocks install clobbers Mudlet install

Post Reply
Malnormalulo
Posts: 3
Joined: Sun Jun 21, 2015 4:14 am

Luarocks install clobbers Mudlet install

Post by Malnormalulo »

I recently set about installing Luarocks (on Win10), and the LUA_PATH parameters it wanted me to set seem to have made Mudlet unhappy. I got around most of it by just adding "C:\Program Files (x86)\Mudlet\mudlet-lua\lua\?.lua" to the LUA_PATH, but Mudlet's still not playing nice with lfs.
[ OK ] - Lua module rex_pcre loaded.
[ OK ] - Lua module zip loaded.
[ ERROR ] - Cannot find Lua module lfs (Lua File System).
Probably will not be able to access Mudlet Lua code.
Lua error:error loading module 'lfs' from file 'C:\Program Files
(x86)\LuaRocks\systree\lib\lua\5.1\lfs.dll':
A dynamic link library (DLL) initialization routine failed.
[ OK ] - Lua module sqlite3 loaded
[ ERROR ] - LuaGlobal.lua compile error - please report!
Error from Lua: mudlet-lua/lua/LuaGlobal.lua:135: attempt to index global 'lfs' (a nil
value)
Looks like some other package installed lfs (a different version, I'm assuming), so Mudlet's looking at my LUA_PATH and trying to use that one. Does anyone have any ideas for how to resolve this? I don't want to have to jury-rig either Mudlet or my other code to use the other's version of lfs.

Malnormalulo
Posts: 3
Joined: Sun Jun 21, 2015 4:14 am

Re: Luarocks install clobbers Mudlet install

Post by Malnormalulo »

I've done some more investigation, and I suspect this might be best solved with a Mudlet code change. Don't know whether this thread is the best place to propose this (maybe a mod can move it to the dev subforum?), but I don't necessarily know a better place.

It seems that Mudlet loads its packages with `require` without first redefining the `package.path` and `package.cpath` variables -- so if the host system has the appropriate environment variables defined, it will always look to the system package repository first. In my case, this means it's finding the version of lfs I pulled from luarocks instead of the vendored one bundled with Mudlet. If the local directories were prepended to the path variables within the Lua runtime, it should safely isolate Mudlet's bundled dependencies from the system repository, while still allowing the system repository to be used.

But I see something similar in this test, which leads me to suspect there was a good reason that this wasn't already done for the startup code.

User avatar
SlySven
Posts: 1019
Joined: Mon Mar 04, 2013 3:40 pm
Location: Deepest Wiltshire, UK
Discord: SlySven#2703

Re: Luarocks install clobbers Mudlet install

Post by SlySven »

Well Mudlet has a dependency on Lua 5.1 and I suspect that most system installs are now 5.2 (or is 5.3 out?)

The loading up of the Lua subsystem is a combination of routines (in void TLuaInterpreter::loadGlobal() and void TLuaInterpreter::initLuaGlobals() in ./src/TLuaInterpreter.cpp) and the LuaGlobal.lua file that loads in the other Mudlet/Geyser specific bits (after "LFS" a.k.a. Lua File System has been pulled in by those C++ methods). The complication that any revisions have to remember to handle all three of MacOS/Windows AND *nix files-system and the placement of files in those if not the same or subdirectory of the final executable (and the code ought to also cover the cases where the application has been built in or alongside the source code as well as installed elsewhere in the three platform types file-system)! :ugeek:

Malnormalulo
Posts: 3
Joined: Sun Jun 21, 2015 4:14 am

Re: Luarocks install clobbers Mudlet install

Post by Malnormalulo »

Yeah, those complications (and the fact that I've never touched C++ in my life) are why I didn't just submit this as a pull request.

The Lua version collision, though, seems to me to compound the issue. That in particular isn't a problem in my case (I installed LuaRocks' embedded runtime, which is 5.1), but I can easily imagine others might have 5.2+ set up on their system. Such setups would probably get a whole lot more startup errors than I did.

Does the structure of Mudlet's vendored libs, relative to the application itself, change between operating systems? Even if they do, I don't imagine it would be an insurmountable challenge. I'd even take it on myself (can't avoid C/C++ forever...), but I wanted to run it by people with a bit more familiarity with the system first.

User avatar
SlySven
Posts: 1019
Joined: Mon Mar 04, 2013 3:40 pm
Location: Deepest Wiltshire, UK
Discord: SlySven#2703

Re: Luarocks install clobbers Mudlet install

Post by SlySven »

As someone hacking away with Mudlet on FreeBSD (which has luarocks as a port but which the default flavour is Lua 5.2 not 5.1) and also trying to get a Cygwin port done (for those who want to get all POSIX-ish on Windows) which doesn't bundle luarocks at all - getting all platforms to work is proving interesting and from personal experiences I know that getting the package.path and package.cpath right for both the main profile Lua instance and the sandboxed lua code formatter {which is run separately to avoid it's artefacts messing up the main instance} right is a pain and in a bit of a state of flux at the moment...

There are some libraries associated with the updater systems which are different for all three prime Os (which Vadi knows more about than I - I usually define WITH_UPDATER=NO in my environment when I'm building on Linux - and it is academic on FreeBSD) also the lua-zip lua module is not available as a shared-library on macOs so on that platform we use a bundled copy of the source code (but pull in the system one on Linux/Windows). :geek:

Post Reply