Re: [ANN] Lua 5.3.4 (rc2) now available,

[Hisham <h@...>]

On 12 January 2017 at 01:26, Jerome Vuarand <jerome.vuarand@gmail.com> wrote:
> 2017-01-11 17:48 GMT+00:00 Hisham <h@hisham.hm>:
>>> Full programs using Lua probably want its own control over the paths
>>> used by the Lua code inside it.
>>
>> They already have it. It's trivial to control package.path and
>> package.cpath programatically from either C or Lua.
>>
>> But what will happen if Lua stops handling environment variables by
>> default is that, in the absence of defaults, each project will adjust
>> its module paths in a slightly incompatible way. The already fragile
>> notion of a Lua ecosystem will be hurt by this change. I could expand
>> on arguments against this if this proposal comes up again for 5.4
>
> Then following that argument, lua_newstate should also load the
> "string" module because many if not most pieces of Lua code out there
> assume the module is preloaded (and has modified the string type
> metatable).

No, when I said that the Lua ecosystem would be hurt by the change,
that last argument was not for the sake of compatibility with existing
codebases. It is for the sake of integration. When installations of
Lua are able to load modules in stardard ways, they integrate better
and are more easily extensible. A practical example: loading a
standard installation LuaFilesystem when writing a plugin for Awesome
WM — if Awesome only used its non-standard library paths and not
relied on the default Lua environment settings, one not be able use
the package manager, would have to install additional copies of the
module in non-standard places and manage that by hand, etc. Just today
at the lab I heard of another example concerning LuaTeX package paths,
which made me immediately think of how more often complaints of that
kind will come up if a change of this kind comes into effect.

> But lua.c has been in charge of that "default behaviour"
> for a long time now.

No, more specifically, luaL_openlibs, *part of liblua.so*, is in
charge of that behavior. That is, people embedding Lua have a standard
way of initializing the state if they want a "default-looking" Lua,
and are not left to their own devices when set up the initial state.
If luaL_openlibs wasn't available, I'm sure that programs out there
embedding Lua would each be loading all sorts of variations of subsets
of the standard libraries. It's important to make it easier to "do the
right thing".

Likewise, there is a certain standard logic that Lua follows when
initializing package paths based on environment variables. Plainly
removing that from the library and having everyone who integrates Lua
reinvent that wheel is asking for trouble.

If having the alternative to avoid the environment variables is
desired, a good alternative for lua 5.4 would be to move this
functionality to the auxiliary library. I'd even suggest making it a
second boolean argument to luaL_openlibs: luaL_openlibs(L, 1); This
would avoid adding an extra function to the API and the compiler error
caused by the extra argument would ensure that integrators who are
initializing a "plain-looking" Lua state wouldn't miss this change
when porting over code from 5.3 to 5.4. It would also avoid the need
for the trick in lua.c that Roberto was unhappy about.

Those wishing for a more minimalistic Lua could easily use
luaL_openlibs(L, 0). Those using a really minimalistic Lua are picking
their libraries one by one and aren't using luaL_openlibs anyway. And
those really concerned with size in embedded systems are probably not
even linking this function. Everyone wins. :)

-- Hisham