lua-users home
lua-l archive

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


Rather than forcing everybody's modules to conform themselves to a naming scheme, I think the way to do this would be to have a "project domain" layout scheme just for finding projects on the new LuaForge (same as the old LuaForge), and then having an extension for Rocks (or similar) that searches within these categorizations hosted as another project on LuaForge.

(Another point of the architecture's design: it should have an API that makes this easy, as well as an easy data dumping facility (to satisfy Eric S. Raymond). I recommend something that dumps as a Lua table (formatted similarly to a Rockspec).

"Michal Kolodziejczyk" <miko@wp.pl> wrote in message 4ACF1D50.7040808@wp.pl">news:4ACF1D50.7040808@wp.pl...
steve donovan wrote:
2009/10/9 Michal Kolodziejczyk <miko@wp.pl>:
Let me recall similar thread:
http://lua-users.org/lists/lua-l/2009-01/msg00211.html

I like the distinction between LOSR (lua open software repository) and
CLAN (like Perl's CPAN).

Namespace agreement can be a mission; it will lead to tedious
arguments and will break a lot of code in the transition.  (E.g.,
require 'cairo' becomes require 'graphics.cairo', and so forth)  The
pragmatic solution is to make it easy LuaForge++ for tell you exactly
what module(s) a package provides. These are not always obvious, e.g.
I know that LuaFileSystem provides 'lfs' but that's because I know the
package.  Then there will be no module conflicts _by mistake_.

I would propose prepending a module name with its home domain name (in
"java way"), so:
require 'org.losr.lfs'
which could be "imported" by CLAN and published as:
require 'org.clan.lfs'
or
require 'org.clan.luafilesystem'

It would by great if it was supported/promoted by luarocks. It would
help resolve conflicting module names, and conflicting files within
different modules.

Regards,
miko