[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Top-level source file name for a package: "?.lua", "?/?.lua", or "?/init.lua"?
- From: "Andre Carregal" <carregal@...>
- Date: Mon, 7 Jan 2008 12:17:20 -0200
On Jan 6, 2008 3:06 AM, Matt Campbell <email@example.com> 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.