Re: [Lua vs Python] Luarocks

[Dennis Fischer <darkwiiplayer@...>]

While I've had my fair share of problems with luarocks, mostly because I
did some weird things and swapped around Lua installations a bit,
overall I really like the way it works. Anyone who frequently uses Ruby
might know this thing called bundler, which makes sure that an
application runs with a specific version of a gem (gem = rock, but for
ruby), and it's quite a pain to work with compared with Luarocks, where
you can just have a local rock tree in your project and a rockfile that
installs the dependancies locally.

More than Luarocks being broken, it often seems to me that many rocks
are just broken and nobody notices, be it because the author doesn't
even use Luarocks or that it's just a personal project turned rock
because why not and nobody cares if the version that's on the internet
doesn't work as long as there's some quick hack to get it working when
needed.

There could be many solutions for this problem; but all of them would
require rock authors to spend more time on things that aren't actually
code and that seems like something the average rock author doesn't want
to be bothered with, like setting up CI/CD on github or even just
manually checking that a given project state installs cleanly on a new
system (VM, container, etc.).

Well, those are my thoughts at least :)

On 19/01/2020 01:47, Eduardo Ochs wrote:
> Hi list,
>
> here are my 2 cents about the Lua vs Python discussion - in a new
> thread.
>
>
> 1) It is unrealistic to ask Roberto and Luiz to choose among rocks
>    that they've never used and bless some of them. Some people use
>    luarocks very little or not at all, and Roberto and Luiz may be
>    some of these people.
>
>
> 2) At this moment it is not very easy to play with a new rock - and it
>    should be!!! Let me give an example. A few days ago I realized that
>    I could find a certain bug easily if I had a debugger - I do have
>    functions that start REPLs and inspect stack frames, but they are
>    quick hacks that I wrote myself and they're not very good, so I
>    went to luarocks.org and got this listing:
>
>      https://luarocks.org/search?q=debug
>
>    I chose "debugger", and did:
>
>      luarocks --local install debugger
>
>    and discovered that now I have these files:
>
>      ~/.luarocks/lib/luarocks/rocks/debugger/scm-1/doc/README.md
>      ~/.luarocks/share/lua/5.1/debugger.lua
>
>    which is great - this one comes with docs, I don't need to fetch
>    the source package! - so I did this,
>
>      lua5.1
>      userocks()   -- defined in my LUA_INIT file
>      require "debugger"
>      -- ...I and got this error:
>      --   stdin:1: module 'debugger' not found: [blabla many lines]
>
>    Voila! Another rock that doesn't work out of the box for me...
>
>
> 3) A few days ago I complained that "luarocks unpack" does not work on
>    my Debian box. My messages are here:
>
>      http://lua-users.org/lists/lua-l/2020-01/msg00099.html
>      http://lua-users.org/lists/lua-l/2020-01/msg00101.html
>      http://lua-users.org/lists/lua-l/2020-01/msg00114.html
>
>
> In an ideal world the problem that I reported in (3) would be
> considered EXTREMELY URGENT - *everybody* would know that the first
> step towards getting 25 millions of Lua users is to have impeccable
> batteries, and the first step towards that is to make luarocks both
> super user-friendly and super hacker-friendly... trying a rock should
> be something incredibly easy for all kinds of people, including people
> who want to look at the source!!!
>
> WE NEED AN ARMY OF LUAROCKS HACKERS.
>
> Cheers,
>   Eduardo Ochs
>   http://angg.twu.net/dednat6.html
>   http://angg.twu.net/emacsconf2019.html
>   http://angg.twu.net/#eev
>

Attachment: signature.asc
Description: OpenPGP digital signature