 |
lua-l archive |
|
|
||
|
I think there are many, many problems with LuaRocks, and I feel like
it's important to acknowledge them and try to fix them, but I think
that the codebase of LuaRocks won't do. I personally started a repo
[1] for exploring an option and alternative to LuaRocks as a package
manger for the Lua ecosystem. Right now it only consists of a list of
concepts, and there is nothing really planned, but it lists the
problems I see with LuaRocks, more or less.
I attached the markdown file with the list below, it is a bit vulgar
but I think it reflects very well my anger towards LuaRocks and my
general worries. The repo is availiable at GitHub[1] and I would
encourage anyone with any suggestion to go there and make an issue so
we can discuss it. (Or, if you don't use GitHub, reply to this). I'm
interested to know what the community thinks of LuaRocks, what we want
to fix and what we want to improve.
[1] https://github.com/daelvn/meteor
On Mon, 20 Jan 2020 at 09:05, Dennis Fischer <darkwiiplayer@hotmail.com> wrote:
>
> I do agree that Luarocks should be more hackable. Personally, I am more
> annoyed that the rockspecs try too hard at being safe, which just makes
> life harder for rock authors. A very typical thing you'll see in ruby
> gemspecs, for example, is that it just calls `git` to get a listing of
> all the source files and simply installs all those. It's also very
> common to have a version.rb file which is then read by the gemspec to
> identify the gem version, while in luarocks you have to maintain the
> rockspec version and the internal version separately, which makes it
> easier to forget one of them.
>
> And I don't even think this could only be fixed by enabling `require`
> and `io.popen` in rockspecs, but could just as well be fixed through a
> combination of luarocks extensions and a mechanism to inject code during
> rock installation.
>
> Somewhere in your rockspec, you could have something like:
>
> build.modules = git.sources('src/*.lua')
> table.insert(build.modules, 'mylib.version', 'return '..version)
>
> Together with more possibilities for users to customize how Luarocks
> does things (maybe through hooks, similar to git?), it could very easily
> become so much better than what all the other languages have.
>
> On 19/01/2020 16:59, Eduardo Ochs wrote:
> > Hi Dennis!
> >
> > Let me disagree! =)
> >
> > Debian has this:
> >
> > https://packages.debian.org/sid/python-apt
> >
> > I've never been able to use it - my brain is wired in a way that makes
> > Python too hard for me - but I have the impression that if luarocks
> > could be made a bit more hackeable then the people who are complaining
> > that Lua's batteries are a mess would change their attitude
> > completely... they would change the tone of their messages and they
> > would start sending things like "hey, I wrote this script here that
> > performs the tests such and such in the latest version of all the
> > existing rocks, and I just discovered that 20% of them fail this test
> > here..."
> >
> > By the way, the last line of /usr/bin/luarocks is:
> >
> > command_line.run_command(...)
> >
> > I've just added these two lines before that one,
> >
> > local myfile = os.getenv "LUAROCKS_DO"
> > if myfile and myfile ~= "" then dofile(myfile) end
> >
> >
> > and I am starting to play with that. My first (super-trivial) tests
> > are here:
> >
> > http://angg.twu.net/LUA/luarocks-extra.lua.html
> >
> > Cheers,
> > Eduardo Ochs
> > http://angg.twu.net/dednat6.html
> > http://angg.twu.net/emacsconf2019.html
> > http://angg.twu.net/#eev
> >
> >
> > On Sun, 19 Jan 2020 at 07:52, Dennis Fischer <darkwiiplayer@hotmail.com> wrote:
> >> 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:
CONCEPT.md
Description: Binary data