Fwd: Undeliverable: "Private" C modules loaded by Rosie module

On 13 Mar 2017, at 15:33, Jamie Jennings <jj27700@gmail.com> wrote:

From: Thijs Schreijer <thijs@thijsschreijer.nl>

Date: Sun, 12 Mar 2017 07:48:34 +0000
Subject: Re: "Private" C modules loaded by Rosie module

Hi Jamie,

loved your talk at last years Lua workshop!

On 10 Mar 2017, at 15:23, Jamie Jennings <jj27700@gmail.com> wrote:

My question is: Am I asking for trouble by taking this approach?

Thijs, thanks for the kind words and for taking the time to give such thoughtful advice to my Rosie question!

Why would you hide those modules?

It is a matter of opinion, but I think I’d rather have created a custom loader, as it (from a Lua perspective) adds less magic. See https://www.lua.org/manual/5.1/manual.html#pdf-package.loaders

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,

Thijs

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. :-)

Jamie