Re: [Luarocks-developers] Luarocks install bug? [was Re: [ANN] stdlib 36 released]

[Hisham <h@...>]

On 16 January 2014 20:19, Gary V. Vaughan <gary@vaughan.pe> wrote:
> Hi Hisham, Dirk,
>
> On Jan 16, 2014, at 10:06 PM, Dirk Laurie <dirk.laurie@gmail.com> wrote:
>
>> 2014/1/16 Gary Vaughan <gary@vaughan.pe>:
>>
>>> I am happy to announce release 36 of stdlib.
>>
>> I have tried this under Lua 5.2.3.
>>
>> - `std=require"std"` does not return a table containing std.set etc
>>   which is assigned to a variable `std` but gives the error message
>> /usr/local/share/lua/5.2/std/debug.lua:6: module 'std.debug_init' not found:
>
> The problem here is that the rockspec says:
>
> ...
> build = {
>   modules = {
>     ["std.debug_init"] = "lib/std/debug_init.lua",
>     ...
>   },
> }
>
> Which I expected to copy the distributed lib/std/debug_init.lua to $prefix/share/lua/5.1/std/debug_init.lua.  But actually it puts it copies it to $prefix/share/lua/5.1/std/debug_init/debug_init.lua!

Odd! I wonder if the "init.lua" suffix triggered some bug. I'll take a
look at it ASAP.

> I'll make a new release with the following ugly workaround that maintains backwards compatibility:
>
>   ["std.debug_init"] = "lib/std/debug_init/init.lua",
>
> I'm not sure how this snuck through my Travis Continuous Integration, but if I can figure it out, I'll change the configuration to notice such things in future.

Same here.

-- Hisham