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

[Hisham <h@...>]

On 11 January 2017 at 10:19, Roberto Ierusalimschy
<roberto@inf.puc-rio.br> wrote:
>> Section 6.3 of the manual states that package.path and package.cpath
>> are initialized by Lua using environment variables LUA_PATH or
>> LUA_CPATH &c. as appropriate.
>>
>> That seems not to be the case for Lua 5.3.4: the code in question
>> has been moved from loadlib.c in 5.3.3 to lua.c in 5.3.4. Thus, the
>> environment variables may only be processed for the stand-alone lua
>> executable.
>
>   | At start-up, Lua initializes this variable with
>   | the value of the environment variable [...]
>
> It does not specify whether "Lua" is the library or the program.  So,
> the manual is imprecise, but not incorrect :-) But yes, that changed
> in 5.3.4 and the manual can be clearer about this matter.

Whoa, I completely missed this because I usually trust 5.3.x versions
to bring no user-visible changes, so I didn't pay close attention.

Are you aware that this breaks a lot of code out there? Every project
embedding Lua out there which relies on the environment paths will no
longer be able to find its modules.

To confirm my suspicions, I just installed Lua 5.3.4-rc2 in my system
and, as I expected, my desktop simply no longer starts, because I
happen to use Awesome WM, a window manager scriptable in Lua.

Please, do not make such a severely breaking change in a 5.3.x release.

> 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, but
for 5.3.4 the verified compatibility breakage should be enough.

-- Hisham