A word of advice against init.lua

[Hisham <h@...>]

Hi list,

I stumbled upon a situation that made me realize an inherent problem
with the foo/init.lua idiom to represent require("foo").

Today I upgraded a module which was moved from foo.lua to
foo/init.lua. Since there was no filesystem conflict, the old module
was kept in its place, without me noticing it. Things later failed,
because require("foo") kept picking the old version, because ?.lua
comes before ?/init.lua in the package.path.

If two different projects use the same module name and the same module
filename, eventual conflicts during installation are easy to detect
(say, via package manager conflicts or failure when running "make
install"). If two different projects use foo.lua and foo/init.lua,
both will install silently and fail during execution, potentially in
strange ways.

Of course one can answer "just be careful about what you install", or
"there shouldn't be any module name conflicts", but since we don't
have a canonical namespace hierarchy for modules, conflicts do happen
(see the various require("json") modules out there for example) and I
believe any procedures to help detect and handle/correct them are
welcome. I've now come to believe that avoiding init.lua is one such
procedure.

(For the argument of "let's just everyone use foo/init.lua and avoid
foo.lua instead", the fact that ?.lua takes precedence means that it
is a more robust option; besides, many projects consist of a single
file.)

-- Hisham
http://hisham.hm/