Re: A major problem with the Lua ecosystem

[Dibyendu Majumdar <mobile@...>]

On 1 February 2018 at 22:13, Dibyendu Majumdar <mobile@majumdar.org.uk> wrote:
> On 1 February 2018 at 08:22, Dirk Laurie <dirk.laurie@gmail.com> wrote:
>> 2018-02-01 0:08 GMT+02:00 Dibyendu Majumdar <mobile@majumdar.org.uk>:
>>> On 31 January 2018 at 22:03, Paul K <paul@zerobrane.com> wrote:
>>>>> require "paths"
>>>>> paths.require "libtorch"
>>>>
>>>>> The paths.lua script is generated from:
>>>>> https://github.com/torch/torch7/blob/master/paths.lua.in
>>>>> I must be missing something here.
>>>>
>>>> I think it's a different paths module. I'd expect it to be this one:
>>>> https://github.com/torch/paths
>>>>
>>>
>>> Ah okay thanks! Strange that there is 'paths.lua' in the Lua script folder.
>>
>> The problem has two parts:
>>
>> 1. The name of the module is often a common word like "paths"
>> which may easily be non-unique.
>> 2. The name under which the module is contributed to LuaRocks
>> is not the same as the name that comes in "require".
>>
>> The Lua team has done what they could: "require" can specify
>> subpaths, which so far seem mostly to be exploited by writers
>> of large module collections.
>>
>> What we as a community shoud do is to agree on a standard
>> directory tree to act as containers. just one or two levels.
>> Then we can say "paths = require 'torch.paths'" and make
>> sure we get the right one.
>>
>
> I didn't even realize that Lua supported require 'a.b.c' and that this
> is translated to a filesystem path, maybe because I haven't seen it
> being used.
>
> Will certainly make sure that all modules in the Ravi distro follow a
> supplier.modue (e.g. torch.paths) pattern - can't imagine why people
> don't do this. It is a no brainer to me.
>


Maybe there is one problem - the require function also loads shared
libraries. Having these in multiple locations could be a problem as
these need to be in the path.

Regards
Dibyendu