lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On Jan 6, 2008 3:06 AM, Matt Campbell <> wrote:
> I've observed three naming conventions for the top-level source file of
> a Lua package, where '?' represents the name of the package:  "?.lua",
> "?/?.lua", and "?/init.lua".  The first and third conventions are
> supported by the default package.path in Lua 5.1.  The first is used in
> the Kepler binary distribution (at least on Windows), and the second is
> used in the source trees of Kepler packages like CGILua and Xavante.  I
> haven't yet seen anyone else use the third, though I use it myself.
> Which is best?  I'm especially curious to know why the Kepler project
> uses different naming conventions in its source and binary
> distributions, and why its source trees use a naming convention that
> Lua's default configuration doesn't support.

This is due to the changes in the default path values used by Lua 5.0,
Compat-5.1 and Lua 5.1.

Lua 5.0 used "?;?.lua" and Compat-5.1 started using "?.lua;?/?.lua"
but then added "?/init.lua" as Lua 5.1 started using it. By then every
Kepler module was already assuming the "?/?.lua" which was not adopted
by Lua 5.1.

In order to make things easier on the CVS side we decided to simply
add makefile rules to handle the difference, moving
/xavante/xavante.lua to /xavante.lua on the make step for example.

> I prefer "?/init.lua" because it most closely follows the DRY (Don't
> Repeat Yourself) principle.  With this convention, a package's directory
> tree looks like this:

We also had some discussions on this subject in the Kepler list but
there was no clear winner solution. From my point of view, those path
related issues are still a problem for those interested in
distributing Lua based command line tools.

In fact, if there is one thing I'd like to see in Lua 5.2 that would
be a better way to handle the module finding part of require(). Tools
that want to intercept require() calls have to repeat a lot of work
today and any improvements on this front would be welcome.