lua-users home
lua-l archive

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

On Fri, Oct 9, 2009 at 9:59 PM, Leaf Storm wrote:
> ...I'm a bit wary of using rockspecs
> as the file format for uploading information. The purposes are
> different, in that rockspecs are mostly intended just to provide
> instructions on creating and installing rocks. Because of this, (a)
> they don't offer fields for things like categories, SCM or bug
> tracking location, alternative downloads, etc., and (b) the build
> instructions are present in the rockspec, and I'm not sure those
> really belong on an index (or even a forge). A similar format could be
> used, though ("metaspec"?), and I like the idea of auto-polling for
> specs. (Possibly, we could use metaspecs for storing the information
> and host rockspecs for projects if they provide one.)

You make an important point.  However, a rockspec file is segmented
into multiple sections.  All the building-from-source info is in the
build section.  Info for deployment (from source or binaries) are in
the source and dependencies sections.  The project metadata you talk
about, however, is largely concentrated in the description section.
If preferred, one may split these into separate files, so it's a small
concern IMO.

A major apparent difference between a rockspec file and a
file (which is LuaDist's version of a rockspec), as seen for example
in comparing [1,2], is that the file in fact lacks a build
section.  This is because the build instructions are nearly entirely
concentrated in an external build file (CMake CMakeLists.txt file).
This, actually, is not that different from a rockspec using a "make"
backend with external Makefile, or more-so a "cmake" backend with
external CMakeLists.txt file.  I've argued [3] for making the format a proper subset of the rockspec format, and we've
taken steps in that direction, or at least to permit automatic
translation, but we haven't constrained ourselves to that, and the
format is still in flux.  I'm interested to see where LuaRocks 2.0 is
going with this too.

The mention above about DOAP [4,5] is interesting because it takes a
more general direction.  The recent design of at least has
been directed by deployment concerns and comparison to existing port
systems and package managers [3].  But DOAP and the things discussed
here can be more about project descriptions.  Note also that a project
can have multiple release, and the rockspec/ files have
generally been descriptions of specific releases (and, for binary
versions, specific platform builds), not necessarily a project as a