[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Difficulties with LuaRocks
- From: Javier Guerra Giraldez <javier@...>
- Date: Mon, 13 Jun 2011 12:08:11 -0500
On Mon, Jun 13, 2011 at 11:29 AM, Rob Kendrick <rjek@rjek.com> wrote:
> What I would find *very* useful is a tool to convert rocks into Debian
> packages. I really don't like having multiple package managers running
> on the same system at the same time :)
i'd love that too; but fear that it might create a family of
debian-compatible rocks that can't use most advanced features of
LuaRocks.
IMNSHO, the best world would be where authors create a rockspec, but
include a readable README with complete requirements and any special
installation procedure. IOW: just a rockspec is NOT enough.
case in point: I wanted to test the telescope package, but couldn't
get any list of dependencies, so just tried to just get on with the
times and install luarocks (from apt), but it barfed with my manual
install of many other Lua packages. in the end it worked, but i don't
really know how, and when i try to follow the chain of includes it
goes to seveal directories that i had never seen before. a _very_ bad
first impression, but i guess it's (in part) my fault because it
wasn't a pure rock-managed install.
what i would like:
- just installing the LuaRocks toolset shouldn't do _anything_ to my
setup. i guess that's true right now; but i have to state as a high
priority
- there should be an easy way to point to a rockspec and show a full
list of dependencies, without installing anything. it's ok to
download lots of rockspecs to follow the whole tree. extra points if
it marks which packages are already on the _standard_ directories,
that is, anything pointed by the current LUA_PATH.
- finally, the default non-local install shouldn't leave _any_ traces
of LuaRocks in the runtime. no new paths, no special rocks_require,
nothing. local Lua universes are a great optional feature, but if it
needs any meddling with either the executable, or LUA_PATH, or pre-run
fake scripts, then it should _NOT_ be the default.
OTOH, this is not the first time i've heard that this is how it's
supposed to work; maybe i have an old version, or some of my efforts
to not allowing it to modify my setup were counterproductive.
BTW, maybe it's not obvious from my rants; but i do know that LuaRocks
are a big help for lots of users and it does lower the cost adopting
Lua. my own priorities are not those of most people, and i'm happy to
manage my packages by hand. my only complain is when a package
assumes LuaRocks and doesn't provide any hint on how to install
manually.
--
Javier