[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: LuaForge is down and will be for some time
- From: "Stuart P.Bentley" <stuart@...>
- Date: Fri, 9 Oct 2009 13:57:46 -0700
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" <email@example.com> wrote in message
steve donovan wrote:
2009/10/9 Michal Kolodziejczyk <firstname.lastname@example.org>:
Let me recall similar thread:
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:
which could be "imported" by CLAN and published as:
It would by great if it was supported/promoted by luarocks. It would
help resolve conflicting module names, and conflicting files within