[Lua vs Python] Luarocks

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[Lua vs Python] Luarocks

Eduardo Ochs
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

Reply | Threaded
Open this post in threaded view
|

Re: [Lua vs Python] Luarocks

Dennis Fischer
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
>


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Lua vs Python] Luarocks

Eduardo Ochs
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 <[hidden email]> 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
> >
>

Reply | Threaded
Open this post in threaded view
|

Re: [Lua vs Python] Luarocks

Dennis Fischer
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 <[hidden email]> 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
>>>


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Lua vs Python] Luarocks

Dael Muñiz
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 <[hidden email]> 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 <[hidden email]> 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
> >>>
>

CONCEPT.md (5K) Download Attachment