How to organize Lua code when 'require' not allowed?

[xeranas]

It seems that by default when I use 'require' I get:

Code: Select all

ERROR[Main]: require() is disabled when mod security is on.

That basically blocker for moding with require. Asking to disable security is simple not solution.

My goal is separate functionality into separate modules and do not expose too much into global scope.
In my case "get_modpath" is useless as it does not allow invoke local functions.

Code: Select all

dofile(minetest.get_modpath("modname") .. "/luaB.lua")

How minetest moders deal with this problem?

[sfan5]

You can return functions from dofile:
https://github.com/Uberi/Minetest-World ... fe.lua#L65
https://github.com/Uberi/Minetest-World ... it.lua#L16

[rubenwardy]

and also tables to expose a local only API

[Linuxdirk]

My goal is separate functionality into separate modules and do not expose too much into global scope.

init.lua

Code: Select all

mymodname = {}

dofile(minetest.get_modpath("modname") .. "/luaB.lua")

mymodname.foo()

luaB.lua

Code: Select all

mymodname.foo = function ()
    -- do something here
end

Now all you expose to the global scope is a table named after your mod.

[xeranas]

My goal is separate functionality into separate modules and do not expose too much into global scope.

init.lua

Code: Select all

mymodname = {}

dofile(minetest.get_modpath("modname") .. "/luaB.lua")

mymodname.foo()

luaB.lua

Code: Select all

mymodname.foo = function ()
    -- do something here
end

Now all you expose to the global scope is a table named after your mod.

"mymodname.foo" becomes public which I do want to avoid.

and also tables to expose a local only API

no point of calling it 'local' if it can be invoked from any other mod.

[rubenwardy]

This is what sfan5 and I were referring to

Code: Select all

local foo = {}

function foo.bar()

end

return foo

then in caller:

Code: Select all

local foo = dofile(...)

foo.bar()

[xeranas]

rubenwardy, thanks seems dotfile does the job.

[Linuxdirk]

"mymodname.foo" becomes public which I do want to avoid.

Yes, that's unfortunate, but Minetest does not have mod namespaces and thus anything that isn't local will be global. This can't be fixed until one of the devs starts caring about mod namespaces.

But with this approach at least you have only one thing (the table) in the global namespace and you can place anything that should be used in several places of your mod there withuot polluting the global namespace even more.

[rubenwardy]

"mymodname.foo" becomes public which I do want to avoid.

This can't be fixed until one of the devs starts caring about mod namespaces.

We simply care more about mod backwards compatibility than mod namespacing. The engine at least warns if you write to a new global that isn't the name of the mod.

Also, this can be fixed by the mod. See my other response