Re: [mildly OT] Some info about Python

[Oliver <oschmidt-mailinglists@...>]

On 03.02.20 17:55, Enrico Colombini wrote:
> On 03-Feb-20 14:49, Roberto Ierusalimschy wrote:
>> Why don't we all rally behind Luarocks and try to fix those drawbacks?

Yes why? Perhaps too much fun doing other things with the Lua programming language.

>>From the big picture view there are two areas where improvements to Luarocks
could be made:

- luarocks website -

Extending collaboration features, tagging and ranking system of projects etc.
For example, currently it is even not possible to contact a rockspec uploader if
the uploader is not the author mentioned in the homepage.

A good and very popular example that can serve as inspiration for improvements
could be the AUR (Arch User Repository): https://aur.archlinux.org/

Here every user can upload package builds (=rockspecs). Each package build has
its own git repository where the history of the package build can be seen. The
upstream sources are separated from the package builds. Packages can be flagged
as outdated or orphaned or can be requested to be remove. Orphaned packages can
be taken over by other users. For each package there is a discussion area about
problems and so on with this package build.


-luarocks tool - see below

> Not a bad idea, but I'd like to point out (as others have done) that binary
> installation on Windows must be painless (read: click-and-go) for
> non-programmers that just want to run and possibly modify Lua applications.
> Also, many programmers are not willing to install a C compiler on Windows and to

Regarding the Luarocks tool I would love to see a cleaner separation of
different layers. Currently Luarocks is providing solutions for different use
cases in an all-in-one solution:

1.) On the lower end it is a description language about what is contained in a
module and how this is has to be assembled to become Lua packages (at least with
the builtin build type).

2.) On the higher end it's also possible to have binary rocks which looks like
Luarocks being a binary distribution.

IMHO it would be good to have these things separated. The higher layer could be
build on top of the lower layer.

There is also not one "higher layer" that would make everyone happy: The higher
layer could also conflict with other binary distributions: each Linux
distribution has its own package management. For Mac there is for example brew
package manager. For Windows there is for example MSYS2. But nothing speaks
against generating a binary Lua distribution out of the lower layer. (For
windows I personally would use MSYS2 as build system and to build a binary
distribution using this, but other people might prefer other toolsets).

For the lower layer things would be easier if there was only the builtin build
type, i.e. only the possibility to specify sources and compiler/linker flags.
With this most modules could be build. Complexer builds would remain external
dependencies.

The builtin build type could be improved. The good thing is: this can currently
be done independently of Luarocks without breaking backward compatibility by
providing external build types, see for example:
https://github.com/osch/luarocks-build-extended#luarocks-build-extended

Perhaps reducing the functionality of luarocks tool to a simple lower layer
would reduce the overall popularity of Luarocks :-( One the other hand, it would
be Lua-like to have a core as simple as possible and to build complexer things
on top of it.

Best regargs,
Oliver