Re: Fwd: LuaRocks, Ease of Use

[Henning Diedrich <hd2010@...>]

On 1/2/11 5:12 PM, steve donovan wrote:

On Sun, Jan 2, 2011 at 5:55 PM, Henning Diedrich <hd2010@eonblast.com> wrote:

# pcall/pathes
* I almost abandoned LuaRocks in the first place for failing to grasp the
ease of the require pcall tweak.

You mean the require 'luarocks.require'? Otherwise I don't understand
the need for pcall.

Yes, `pcall(require, "luarocks.require")`

# make/compile failure
* -fPIC or what it was called.

A very common problem - LuaRocks will now always use it on a Unix-like
system[1]. But if LuaRocks is using a makefile, then it is only as
good as the makefile. And writing good portable makefiles is an art
which not everyone masters....

The blame falls to the wrong people in any case, even when on those who
contribute modules but don't have opportunity to test exceedingly.

I thought LuaRocks could be a very pragmatic spot to centralize deploy tests for
many modules included. Can one contribute, by triggering some "test all" option
that makes it try to pull and install anything it can and registers and reports back
failures?

If there was, adding a line displayed at the end of every `luarocks install ...`
saying "Contribute now by doing luarocks test-all and send results to ..." could
be the right thing to garner support from users = beneficiaries.

whatever reasons (NOT for me not trying) I could not find it, could not even
find the Rocks file itself, as it kept being pasted in tmp and then deleted.

That used to irritate me, then I learned that the thing to do is
'luarocks unpack MOD' , which expands the rock locally, and then go to
the directory and do 'luarocks make' to explicitly build it.

Which lay beyond my efforts of finding out obviously. I'd opt for a brief
hint to that option to be displayed if things fail. Failure, even for LuaRocks,
will just always happen so "less black box" would be a virtue, even if one
hopes it's never needed. Especially this compile flag problem is of course in
no way LuaRocks specific, it happens all the time with package/module
managers. I'd be grateful for a one-liner in the error message to start me
out, specifically on fixing flags any time. There will always be the next
chaos after shared and 32/64 bit have been settled.

Henning