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

[Marc Balmer <marc@...>]

Am 11.01.17 um 18:48 schrieb Hisham:
> 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.

I actually like this change.  I don't think libraries should deal with
the environment.