I am hiding the modules because I don't want them to interfere with anything else the user loads. I had forgotten that name collisions in the Lua registry could create such interference, particularly if Rosie and the user load different but incompatible
versions of the same C library. (Thanks for reminding me!)
Regarding package.loaders/package.searchers, I'm not certain how to use them here. Is it common for a module to add a searcher to the list? Or were you thinking of package.preload, which I could use to make available Rosie modules (lpeg and
others) without polluting _G?
considering your answer below, that Rosie itself is installed outside of the regular Lua eco system, pretty much makes the loader approach impossible. I had in mind to compare by path upon requiring,
Also: you’re setting a variable `ROSIE_HOME`, in your initial module you could use the output of `debug.getinfo(1)` to dynamically determine where it is located.
True, but I believe that in my approach, the 'rosie.lua' file can be placed in, e.g. /usr/local/lib/lua/5.3 while the rosie installation remains wherever it was installed on the system.
This relates much to the “why” question above. If you’re targeting regular Lua users with this, then I wouldn’t worry to much about the dependency hell.
This is another good point. Regular Lua users are accustomed to managing Lua dependencies, whether native or pure-Lua.
If the intend is packaging in some user application and have Rosie work its magic behind the scenes, then I’d probably use some protection like your hiding of the underlying modules.
That was my intention, indeed: to have a single Rosie installation on a machine serve all users, including Lua programmers.
As in that case a user wouldn’t have a clue probably as to what was wrong when getting an error.
They would get the same information as any other Rosie user. A Lua programmer may dig into the situation and get more information, since Rosie is written in Lua, but only if I expose the Rosie modules in some way. In my development branch (tranche-2)
I provide rosie._env which gives access to the private environment containing all the Rosie modules, e.g. rosie._env.compile is the compiler.
I was thinking to remove rosie._env before release of v1.0, but now I am thinking to keep it, perhaps even to document it. :-)