Re: [ANN] LuaRocks 3.0.0beta1 for Unix

[Hugo Musso Gualandi <hgualandi@...>]

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

That big Installation section is exactly what I was originally looking
for. Thank you!

> Due to the lack of upstream standardization for versioned naming
> there...

Ah, that makes sense. Fedora doesn't seem to have the separate 5.x
packages that Debian and Ubuntu do.

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

I understand that keeping backwards compatibility is a good idea but I
was wondering if Luarocks 3 would let me avoid needing to set those
environment vars in the first place.

Now that the workflow for "repository local" packages is to have a
"./luarocks" launcher I though it would be natural that the workflow
for the "home packages" could be to have a "~/.local/bin/luarocks"
launcher in my path, overriding /usr/bin/luarocks. But maybe I am just
thinking too much here...

> (It does detect some common licenses and fills that field for you

I was playing around with an empty repository so there wasn't anything
to autodetect. Maybe we could make the autodetection more discoverable,
by mentioning it either in the "luarocks init" output or in the
rockspec template iteself?

When I saw the "please specify a license" message I got the impression
that I would need to go after one of those license lists[1] to find out
the specific short license name that I should use to please the
algorithms, as I would need to do when authoring an RPM package. If
only I knew Luarocks would do this for me if I had provided it with a
LICENSE file... :)

[1] https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#Good_Lic
enses