Re: [ANN] LuaRocks 3.0.0beta1 for Unix

[Hisham <h@...>]

On 5 July 2018 at 00:33, Hugo Musso Gualandi <hgualandi@inf.puc-rio.br> wrote:
> It is great to hear that Luarocks 3.0 is finally arriving!
>
> I'd like to offer some feedback based on my experience playing with
> Luarocks 3.0 for a couple of minutes but not doing anything serious
> with it yet.

Great! This kind of first-impressions feedback is very valuable.

> First thing: after a some time installing Luarocks via my distro's
> package manager I had forgotten how to install it by hand. To my
> confusion, I failed to find instructions on the README or an INSTALL
> file explaining what to do. Eventually I fell back on my instincts and
> tried "./configure --help", which worked. It was only after I was
> already using Luarocks 3.0 for a while that I did I notice that the
> info I needed was there all along, in the last sentence of the README
> file. I suppose that my years of reading Wikipedia tricked me into
> thinking that the blue "Unix" link there would have linked to
> information about the operating system instead of linking to http://lua
> rocks.org/en/Installation_instructions_for_Unix. I wonder if this could
> have been more blunt, for people like me :)

I pushed a small update to README.md, does that look better?

https://github.com/luarocks/luarocks

> While we are talking about installation, is the "Making a self-
> contained installation" still relevant now that we have "luarocks
> init"?

That is still possible (I kept the --force-config option around), but
should probably be renamed to avoid confusion.

> Second thing: what is the rule that Luarocks uses to detect the
> currently installed Lua version? I expected it would pick /usr/bin/lua
> (5.3) but by default it chose /usr/bin/luajit instead. I had to use
> "./configure --lua-version=5.3" to override that decision

Due to the lack of upstream standardization for versioned naming there
is a multitude of paths where Lua files are installed on Unix, so we
resort to heuristics. It currently tries all possible suffixed names
first (starting from the highest known version downwards) and the most
ambiguous one (the unsuffixed "lua") as a last resort.

> My third is point a workflow question: Right now I have Luarocks
> isntalled to /usr/bin (from the package manager) and I install many
> packages with  "luarocks install --local". I have a line in my bashrc
> that uses "luarocks --path" to set the necessary environment variables.
> Is this obsolete in Luarocks 3.0 or should I continue doing the same
> thing?

No, this is not obsolete, this workflow is still supported. We tried
to make LuaRocks 3 not break any existing workflows.

If you choose to use `luarocks init` in a project, it will give you a
local tree in that project and the `luarocks` command-line tool will
detect when you are inside that project's directory (like `git` does,
detecting the `.git` directory), and will work using that project tree
if you don't specify any tree flag (`--local` or `--tree`). If you use
`--local` when inside a project, it will ignore the project and
install to $HOME/.luarocks the way `--local` always did.

> The final thing that I noticed that if I don't fill in the rockspec
> template that "luarocks init" creates then when I run "luarocks build"
> then luarocks will hapilly point out that the license is "*** please
> specify a license ***". Would it be possible for it to know that the
> license is actually "unspecified"?

It knows it's unspecified, that's why it's asking you to specify one.
:) (It does detect some common licenses and fills that field for you
in case you have a license in your repo — let me know if that failed!)

Eventually in the future `luarocks upload` should lint rockspecs and
require that field to be filled when uploading to the repository.

Thank you for all the feedback!

-- Hisham