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

[Jerome Vuarand <jerome.vuarand@...>]

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). But lua.c has been in charge of that "default behaviour"
for a long time now.

In contrast I'm the kind to think defaults should be minimalistic. For
example I patch my own Lua so that luaL_openlibs only load "base" and
"package", and while my lua.exe loads the rest, I have added a -l-
option to suppress that behaviour.

So I, for one, think that environment variable change was a good idea.
I agree it might have been too significant a change for a 5.3.x, the
lua.c interpreter is after all meant as a demo client for the
interpreter library, and as such defines what the client is
responsible for. Adding responsibilities to the client is an
incompatible change. However as a subjectively good change, I'll
welcome it if it's back in 5.4.0.