[ANN] LuaRocks 3.0.0beta1 for Unix

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

[ANN] LuaRocks 3.0.0beta1 for Unix

Hisham
Hello list,

I am extremely happy to announce LuaRocks 3.0.0beta1, the
almost-finished package for the new major release of LuaRocks, the Lua
package manager.

***
First of all: "Why beta1?" — the code itself is release-candidate
quality, but I decided to call this one beta1 and not rc1 because the
Windows package is not ready yet, and I wanted to get some early
feedback on the Unix build while I complete the final touches of the
Windows package.

This is NOT going to be a long-or-endless beta cycle: if no major
showstoppers are reported, the final 3.0.0 release, including Unix and
Windows packages, is expected to arrive in one week. But please, if
you want to help out with LuaRocks, give this beta1 a try and report
any findings!
***

Yes, it's finally here! After a way-too-long gestation period,
LuaRocks 3 is about ready to see the light of day. And it includes a
lot of new stuff:

- New rockspec format
- New commands, including `luarocks init` for per-project workflows [1]
- New flags, including `--lua-dir` and `--lua-version` for using
multiple Lua installs with a single LuaRocks
- New build system, gearing towards a new distribution model [2]
- General improvements, including namespaces [3]
- User-visible changes, including some breaking changes
- Internal changes

All of the above are detailed here:

* https://github.com/luarocks/luarocks/blob/master/CHANGELOG.md

I'll try to write up more documentation between now and the final
release. Feedback is wanted regarding what needs to be
documented/explained! And help updating the wiki is especially
welcome.

And without further ado, the tarball for Unix is here:

https://luarocks.github.io/luarocks/releases/luarocks-3.0.0beta1.tar.gz

This release contains new code by Thijs Schreijer, George Roman, Peter
Melnichenko, Kim Alvefur, Alec Larson, Evgeny Shulgin, Michal Cichra,
Daniel Hahler, and myself.

Very special thanks to my employer Kong, for sponsoring my work on
LuaRocks over the last year and making this release possible. Thanks
also to my colleagues Aapo Talvensaari and Enrique García Cota for
helping out with some last-minute testing.

In the name of everyone in the LuaRocks development team, thank you
for the continued amazing support that Lua community has been giving
LuaRocks over the years: keep on rockin'!

Cheers!!!

Hisham Muhammad
-- LuaRocks lead developer
-- https://luarocks.org

[1] https://github.com/luarocks/luarocks/wiki/Project:-LuaRocks-per-project-workflow
[2] https://github.com/luarocks/luarocks/wiki/Project:-LuaRocks-new-distribution-model
[3] https://github.com/luarocks/luarocks/wiki/Namespaces

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] LuaRocks 3.0.0beta1 for Unix

Sean Conner
It was thus said that the Great Hisham once stated:
> Hello list,
>
> I am extremely happy to announce LuaRocks 3.0.0beta1, the
> almost-finished package for the new major release of LuaRocks, the Lua
> package manager.

  I still see no way to cleanly specify a particular version of C to compile
with.  CC will give you the system default, which may be C89, C99 or C11
(unlikely, but hey, it's possible).  I don't want to assume everyone has C99
enabled (I'm looking at your, Windows!) and this has always been a painpoint
with my use of LuaRocks.

  I can also see this being an issue with modules written in C++, as a
cursory search revealed the following versions:

        C++98 (1st edition)
        C++03 (2nd edition)
        C++11 (3rd edition)
        C++14 (4th edition)
        C++17 (5th edition)

and not all are compatible (same way as C99 is not fully compatible with
C89).  It would be nice if I had a way to say, in the rockspec file, "I want
this module to compile with C99 semantics" or "I want this module to compile
with C++11 semantics".

  You already support multiple Lua versions.  At least support multiple
C/C++ versions as well.

  -spc

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] LuaRocks 3.0.0beta1 for Unix

Hugo Musso Gualandi
In reply to this post by Hisham
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.

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 :)

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

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

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?

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"?

-- Hugo

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] LuaRocks 3.0.0beta1 for Unix

Hisham
In reply to this post by Sean Conner
On 4 July 2018 at 20:18, Sean Conner <[hidden email]> wrote:
>   You already support multiple Lua versions.  At least support multiple
> C/C++ versions as well.

Thank you for the feedback — patches are definitely welcome!

-- Hisham

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] LuaRocks 3.0.0beta1 for Unix

Matthew Wild
In reply to this post by Hisham
On 4 July 2018 at 23:36, Hisham <[hidden email]> wrote:
> Hello list,
>
> I am extremely happy to announce LuaRocks 3.0.0beta1, the
> almost-finished package for the new major release of LuaRocks, the Lua
> package manager.

Build and installation was great! The configure script magically found
my 5.4 installation and just worked.

Then I successfully installed luasocket, though it seemed to install
to the current dir (which happened to be the luarocks source dir I
built from). On reading the changelog, I guess this is expected
behaviour.

However now everything seems to fail (regardless of where I run
luarocks from), all commands fail with:

$ sudo luarocks-5.4 list
/usr/local/bin/lua5.4:
/usr/local/share/lua/5.4/luarocks/core/path.lua:17: assertion failed!
stack traceback:
    [C]: in function 'assert'
    /usr/local/share/lua/5.4/luarocks/core/path.lua:17: in function
'luarocks.path.rocks_dir'
    /usr/local/share/lua/5.4/luarocks/path.lua:216: in function
'luarocks.path.use_tree'
    /usr/local/share/lua/5.4/luarocks/cmd.lua:215: in upvalue
'process_tree_flags'
    /usr/local/share/lua/5.4/luarocks/cmd.lua:394: in function
'luarocks.cmd.run_command'
    /usr/local/bin/luarocks-5.4:35: in main chunk
    [C]: in ?


It looks like path.rocks_dir() is passed nil, and cfg.root_dir is nil
also. Is this expected behaviour? Did I do something wrong?

Regards,
Matthew

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] LuaRocks 3.0.0beta1 for Unix

Hisham
In reply to this post by Hugo Musso Gualandi
On 5 July 2018 at 00:33, Hugo Musso Gualandi <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] LuaRocks 3.0.0beta1 for Unix

Hisham
In reply to this post by Matthew Wild
On 5 July 2018 at 10:00, Matthew Wild <[hidden email]> wrote:

> On 4 July 2018 at 23:36, Hisham <[hidden email]> wrote:
>> Hello list,
>>
>> I am extremely happy to announce LuaRocks 3.0.0beta1, the
>> almost-finished package for the new major release of LuaRocks, the Lua
>> package manager.
>
> Build and installation was great! The configure script magically found
> my 5.4 installation and just worked.
>
> Then I successfully installed luasocket, though it seemed to install
> to the current dir (which happened to be the luarocks source dir I
> built from). On reading the changelog, I guess this is expected
> behaviour.
>
> However now everything seems to fail (regardless of where I run
> luarocks from), all commands fail with:
>
> $ sudo luarocks-5.4 list
> /usr/local/bin/lua5.4:
> /usr/local/share/lua/5.4/luarocks/core/path.lua:17: assertion failed!
> stack traceback:
>     [C]: in function 'assert'
>     /usr/local/share/lua/5.4/luarocks/core/path.lua:17: in function
> 'luarocks.path.rocks_dir'
>     /usr/local/share/lua/5.4/luarocks/path.lua:216: in function
> 'luarocks.path.use_tree'
>     /usr/local/share/lua/5.4/luarocks/cmd.lua:215: in upvalue
> 'process_tree_flags'
>     /usr/local/share/lua/5.4/luarocks/cmd.lua:394: in function
> 'luarocks.cmd.run_command'
>     /usr/local/bin/luarocks-5.4:35: in main chunk
>     [C]: in ?
>
>
> It looks like path.rocks_dir() is passed nil, and cfg.root_dir is nil
> also. Is this expected behaviour?

Definitely not!

Let's try to diagnose this:

* Did you install using `make; sudo make install` or `sudo make bootstrap`?
* Did it create a config file /usr/local/etc/luarocks/config-5.4.lua?
  If so, what are its contents?
* Also, could you paste the /usr/local/bin/luarocks launcher script?

Also, the installer failed to create the versioned `luarocks-5.4`
symlink, right? Just noticed that.

Thank you!

-- Hisham

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] LuaRocks 3.0.0beta1 for Unix

Hugo Musso Gualandi
In reply to this post by Hisham
> 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

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] LuaRocks 3.0.0beta1 for Unix

Matthew Wild
In reply to this post by Hisham
Hi, sorry for the delayed response, I was travelling yesterday.

On 5 July 2018 at 15:01, Hisham <[hidden email]> wrote:
> On 5 July 2018 at 10:00, Matthew Wild <[hidden email]> wrote:
>> It looks like path.rocks_dir() is passed nil, and cfg.root_dir is nil
>> also. Is this expected behaviour?
>
> Definitely not!
>
> Let's try to diagnose this:
>
> * Did you install using `make; sudo make install` or `sudo make bootstrap`?

I ran make and sudo make install

> * Did it create a config file /usr/local/etc/luarocks/config-5.4.lua?

Yes:

<<<<<<<<<<
-- LuaRocks configuration

rocks_trees = {
   { name = "user", root = home .. "/.luarocks" },
   { name = "system", root = "/usr/local" },
}
lua_interpreter = "lua5.4"
variables = {
   LUA_DIR = "/usr/local",
   LUA_BINDIR = "/usr/local/bin",
}
<<<<<<<<<<

> * Also, could you paste the /usr/local/bin/luarocks launcher script?
>
> Also, the installer failed to create the versioned `luarocks-5.4`
> symlink, right? Just noticed that.

Ah right, indeed, it created /usr/local/bin/luarocks (no suffix) after
the 'make install'. I ran that and it confirmed it was using Lua 5.4
so I simply moved it manually to /usr/local/bin/luarocks-5.4.

The launcher seems (to me) to be as expected, content follows:

<<<<<<<<<<
#!/usr/local/bin/lua5.4
package.loaded['luarocks.core.hardcoded'] = { SYSCONFDIR =
[[/usr/local/etc/luarocks]] }
package.path=[[/usr/local/share/lua/5.4/?.lua;]] .. package.path

local loader = require("luarocks.loader")
local cmd = require("luarocks.cmd")

local description = "LuaRocks main command-line interface"

local commands = {
   help = "luarocks.cmd.help",
   init = "luarocks.cmd.init",
   pack = "luarocks.cmd.pack",
   unpack = "luarocks.cmd.unpack",
   build = "luarocks.cmd.build",
   install = "luarocks.cmd.install",
   search = "luarocks.cmd.search",
   list = "luarocks.cmd.list",
   remove = "luarocks.cmd.remove",
   make = "luarocks.cmd.make",
   download = "luarocks.cmd.download",
   path = "luarocks.cmd.path",
   show = "luarocks.cmd.show",
   new_version = "luarocks.cmd.new_version",
   lint = "luarocks.cmd.lint",
   write_rockspec = "luarocks.cmd.write_rockspec",
   purge = "luarocks.cmd.purge",
   doc = "luarocks.cmd.doc",
   upload = "luarocks.cmd.upload",
   config = "luarocks.cmd.config",
   which = "luarocks.cmd.which",
   test = "luarocks.cmd.test",
}

cmd.run_command(description, commands, "luarocks.cmd.external", ...)
<<<<<<<<<<

Regards,
Matthew

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] LuaRocks 3.0.0beta1 for Unix

François Perrad
In reply to this post by Hisham


2018-07-05 0:36 GMT+02:00 Hisham <[hidden email]>:
Hello list,

I am extremely happy to announce LuaRocks 3.0.0beta1, the
almost-finished package for the new major release of LuaRocks, the Lua
package manager.



With Buildroot (embedded linux), I run `configure --prefix=my_path`.
The installed `luarocks` script is properly patched with :
    package.loaded['luarocks.core.hardcoded'] = { SYSCONFDIR = [[my_path/etc/luarocks]] }

cfg.init is called a first time by loaded.lua:19, SYSCONFDIR is present in luarocks.core.hardcoded,
and the config file (my_path/etc/luarocks/config-5.3.lua) is successfully loaded.

At the end of loader.lua, package.loaded['luarocks.core.hardcoded'] is removed (with all others luarocks.*).

cfg.init is called a second time by cmd.lua:364, but now the config file is not found.

A workaround is to set the environment variable LUAROCKS_SYSCONFDIR with my_path/etc/luarocks.
With this workaround, rocks are successfully built (including cross-compilation).

But I think that the condition in loader.lua:267 must be inverted.

François
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] LuaRocks 3.0.0beta1 for Unix

Hisham
On 6 July 2018 at 14:57, François Perrad <[hidden email]> wrote:

>
>
> 2018-07-05 0:36 GMT+02:00 Hisham <[hidden email]>:
>>
>> Hello list,
>>
>> I am extremely happy to announce LuaRocks 3.0.0beta1, the
>> almost-finished package for the new major release of LuaRocks, the Lua
>> package manager.
>>
>>
>
> With Buildroot (embedded linux), I run `configure --prefix=my_path`.
> The installed `luarocks` script is properly patched with :
>     package.loaded['luarocks.core.hardcoded'] = { SYSCONFDIR =
> [[my_path/etc/luarocks]] }
>
> cfg.init is called a first time by loaded.lua:19, SYSCONFDIR is present in
> luarocks.core.hardcoded,
> and the config file (my_path/etc/luarocks/config-5.3.lua) is successfully
> loaded.
>
> At the end of loader.lua, package.loaded['luarocks.core.hardcoded'] is
> removed (with all others luarocks.*).
>
> cfg.init is called a second time by cmd.lua:364, but now the config file is
> not found.

Thank you for digging through this!

> A workaround is to set the environment variable LUAROCKS_SYSCONFDIR with
> my_path/etc/luarocks.
> With this workaround, rocks are successfully built (including
> cross-compilation).
>
> But I think that the condition in loader.lua:267 must be inverted.

The problem was not in loader.lua:267, but that bin/luarocks needs a
`require("luarocks.core.cfg")` before `require("luarocks.loader")`.
The `is_clean` variable is there to detect if the environment was
"clean" before calling luarocks.loader (i.e. no LuaRocks modules
around, as in a third-party application that uses luarocks.loader).
So, if the environment "is clean" at the beginning, when
luarocks.loader is done setting up, it cleans all other luarocks
references. The problem was that, since the require was removed from
bin/luarocks, luarocks.loader thought it was running from a "clean"
environment (and not from bin/luarocks).

Still, this exposes a deeper problem: even with that fix, if
luarocks.loader is used standalone from an application, it won't find
the sysconfig file. I think loader.lua will have to be patched upon
installation to get a hardcoded.SYSCONFDIR the same way that
bin/luarocks currently is. We moved the various configurations that
were in the site_config module into the LuaRocks config file proper,
but we need at least one hardcoded entry in order to find the config
file itself.

Once again, thank you! I am going to provide a fix and release a beta2 package.

I'm still a bit puzzled by Matthew's error message, though. Not
finding a config file should produce a default configuration, but not
crash — I was able to reproduce the problem you described, but not his
crash.

-- Hisham

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] LuaRocks 3.0.0beta1 for Unix

Matthew Wild
In reply to this post by Matthew Wild
On 6 July 2018 at 13:04, Matthew Wild <[hidden email]> wrote:

> Hi, sorry for the delayed response, I was travelling yesterday.
>
> On 5 July 2018 at 15:01, Hisham <[hidden email]> wrote:
>> On 5 July 2018 at 10:00, Matthew Wild <[hidden email]> wrote:
>>> It looks like path.rocks_dir() is passed nil, and cfg.root_dir is nil
>>> also. Is this expected behaviour?
>>
>> Definitely not!
>>
>> Let's try to diagnose this:

Any hints here? Any idea if it's a bug, or something related to my
environment/installation procedure?

Regards,
Matthew

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] LuaRocks 3.0.0beta1 for Unix

Hisham
On 10 July 2018 at 15:41, Matthew Wild <[hidden email]> wrote:

> On 6 July 2018 at 13:04, Matthew Wild <[hidden email]> wrote:
>> Hi, sorry for the delayed response, I was travelling yesterday.
>>
>> On 5 July 2018 at 15:01, Hisham <[hidden email]> wrote:
>>> On 5 July 2018 at 10:00, Matthew Wild <[hidden email]> wrote:
>>>> It looks like path.rocks_dir() is passed nil, and cfg.root_dir is nil
>>>> also. Is this expected behaviour?
>>>
>>> Definitely not!
>>>
>>> Let's try to diagnose this:
>
> Any hints here? Any idea if it's a bug, or something related to my
> environment/installation procedure?

I wasn't unable to pin it down yet, but I might have fixed it
indirectly. Please try this:

https://luarocks.github.io/luarocks/releases/luarocks-3.0.0beta2.tar.gz

(Yes, this is a very low-key announcement of another beta package :) )

-- Hisham

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] LuaRocks 3.0.0beta1 for Unix

François Perrad

2018-07-11 1:23 GMT+02:00 Hisham <[hidden email]>:

I wasn't unable to pin it down yet, but I might have fixed it
indirectly. Please try this:

https://luarocks.github.io/luarocks/releases/luarocks-3.0.0beta2.tar.gz

(Yes, this is a very low-key announcement of another beta package :) )


beta2 works fine with Buildroot.

François

-- Hisham


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] LuaRocks 3.0.0beta1 for Unix

Matthew Wild
In reply to this post by Hisham
On 11 July 2018 at 00:23, Hisham <[hidden email]> wrote:

> On 10 July 2018 at 15:41, Matthew Wild <[hidden email]> wrote:
>> On 6 July 2018 at 13:04, Matthew Wild <[hidden email]> wrote:
>>> Hi, sorry for the delayed response, I was travelling yesterday.
>>>
>>> On 5 July 2018 at 15:01, Hisham <[hidden email]> wrote:
>>>> On 5 July 2018 at 10:00, Matthew Wild <[hidden email]> wrote:
>>>>> It looks like path.rocks_dir() is passed nil, and cfg.root_dir is nil
>>>>> also. Is this expected behaviour?
>>>>
>>>> Definitely not!
>>>>
>>>> Let's try to diagnose this:
>>
>> Any hints here? Any idea if it's a bug, or something related to my
>> environment/installation procedure?
>
> I wasn't unable to pin it down yet, but I might have fixed it
> indirectly. Please try this:
>
> https://luarocks.github.io/luarocks/releases/luarocks-3.0.0beta2.tar.gz
>
> (Yes, this is a very low-key announcement of another beta package :) )

Working great, thanks!!

Regards,
Matthew

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] LuaRocks 3.0.0beta1 for Unix

Hisham
On 11 July 2018 at 11:30, Matthew Wild <[hidden email]> wrote:
>> https://luarocks.github.io/luarocks/releases/luarocks-3.0.0beta2.tar.gz
>>
>> (Yes, this is a very low-key announcement of another beta package :) )
>
> Working great, thanks!!

On 11 July 2018 at 11:19, François Perrad <[hidden email]> wrote:
>
> beta2 works fine with Buildroot.

Great to hear, thank you both!!

-- Hisham

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] LuaRocks 3.0.0beta1 for Unix

Russell Haley
In reply to this post by Hisham


On Wed, Jul 4, 2018 at 3:36 PM, Hisham <[hidden email]> wrote:
Hello list,

I am extremely happy to announce LuaRocks 3.0.0beta1, the
almost-finished package for the new major release of LuaRocks, the Lua
package manager.

***
First of all: "Why beta1?" — the code itself is release-candidate
quality, but I decided to call this one beta1 and not rc1 because the
Windows package is not ready yet, and I wanted to get some early
feedback on the Unix build while I complete the final touches of the
Windows package.

This is NOT going to be a long-or-endless beta cycle: if no major
showstoppers are reported, the final 3.0.0 release, including Unix and
Windows packages, is expected to arrive in one week. But please, if
you want to help out with LuaRocks, give this beta1 a try and report
any findings!
***

Yes, it's finally here! After a way-too-long gestation period,
LuaRocks 3 is about ready to see the light of day. And it includes a
lot of new stuff:

- New rockspec format
- New commands, including `luarocks init` for per-project workflows [1]
- New flags, including `--lua-dir` and `--lua-version` for using
multiple Lua installs with a single LuaRocks
- New build system, gearing towards a new distribution model [2]
- General improvements, including namespaces [3]
- User-visible changes, including some breaking changes
- Internal changes

All of the above are detailed here:

* https://github.com/luarocks/luarocks/blob/master/CHANGELOG.md

I'll try to write up more documentation between now and the final
release. Feedback is wanted regarding what needs to be
documented/explained! And help updating the wiki is especially
welcome.

And without further ado, the tarball for Unix is here:

https://luarocks.github.io/luarocks/releases/luarocks-3.0.0beta1.tar.gz

This release contains new code by Thijs Schreijer, George Roman, Peter
Melnichenko, Kim Alvefur, Alec Larson, Evgeny Shulgin, Michal Cichra,
Daniel Hahler, and myself.

Very special thanks to my employer Kong, for sponsoring my work on
LuaRocks over the last year and making this release possible. Thanks
also to my colleagues Aapo Talvensaari and Enrique García Cota for
helping out with some last-minute testing.

In the name of everyone in the LuaRocks development team, thank you
for the continued amazing support that Lua community has been giving
LuaRocks over the years: keep on rockin'!

Cheers!!!

Hisham Muhammad
-- LuaRocks lead developer
-- https://luarocks.org

[1] https://github.com/luarocks/luarocks/wiki/Project:-LuaRocks-per-project-workflow
[2] https://github.com/luarocks/luarocks/wiki/Project:-LuaRocks-new-distribution-model
[3] https://github.com/luarocks/luarocks/wiki/Namespaces

Hi Hisham,

I'm working on getting LuaRocks 3.0 into the FreeBSD ports tree. The port Makefile is here: https://reviews.freebsd.org/D16274

I am getting an error trying to build luarocks-admin. Any help would be great.

Thanks! Russ


russellh@g1 ~/f/p/d/lua-luarocks> make
===>  License MIT accepted by the user
===>   lua53-luarocks-3.0.0 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by lua53-luarocks-3.0.0 for building
===>  Extracting for lua53-luarocks-3.0.0
=> SHA256 Checksum OK for luarocks-3.0.0beta2.tar.gz.
===>  Patching for lua53-luarocks-3.0.0
===>   lua53-luarocks-3.0.0 depends on shared library: liblua-5.3.so - found (/usr/local/lib/liblua-5.3.so)
===>  Configuring for lua53-luarocks-3.0.0

Configuring LuaRocks...

Lua interpreter found: /usr/local/bin/lua53
Checking if /usr/local/bin/lua53 is Lua version 5.3... yes
lua.h found: /usr/local/include/lua53/lua.h
unzip found in PATH: /usr/bin

Done configuring.

LuaRocks will be installed at......: /usr/local
LuaRocks will install rocks at.....: /usr/local
LuaRocks configuration directory...: /usr/local/etc/luarocks
Using Lua from.....................: /usr/local
Lua include directory..............: /usr/local/include/lua53

* Type make build and make install:
  to install to /usr/local as usual.
* Type make bootstrap:
  to install LuaRocks into /usr/local as a rock.

===>  Building for lua53-luarocks-3.0.0
make[2]: make[2]: don't know how to make ./luarocks-admin. Stop

make[2]: stopped in /usr/home/russellh/freebsd/ports/devel/lua-luarocks/work/luarocks-3.0.0beta2
===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
the maintainer.
*** Error code 1

Stop.
make[1]: stopped in /usr/home/russellh/freebsd/ports/devel/lua-luarocks
*** Error code 1

Stop.
make: stopped in /usr/home/russellh/freebsd/ports/devel/lua-luarocks
russellh@g1 ~/f/p/d/lua-luarocks>



Reply | Threaded
Open this post in threaded view
|

Re: [ANN] LuaRocks 3.0.0beta1 for Unix

Russell Haley


On Sat, Jul 14, 2018 at 9:29 PM, Russell Haley <[hidden email]> wrote:


On Wed, Jul 4, 2018 at 3:36 PM, Hisham <[hidden email]> wrote:
Hello list,

I am extremely happy to announce LuaRocks 3.0.0beta1, the
almost-finished package for the new major release of LuaRocks, the Lua
package manager.

***
First of all: "Why beta1?" — the code itself is release-candidate
quality, but I decided to call this one beta1 and not rc1 because the
Windows package is not ready yet, and I wanted to get some early
feedback on the Unix build while I complete the final touches of the
Windows package.

This is NOT going to be a long-or-endless beta cycle: if no major
showstoppers are reported, the final 3.0.0 release, including Unix and
Windows packages, is expected to arrive in one week. But please, if
you want to help out with LuaRocks, give this beta1 a try and report
any findings!
***

Yes, it's finally here! After a way-too-long gestation period,
LuaRocks 3 is about ready to see the light of day. And it includes a
lot of new stuff:

- New rockspec format
- New commands, including `luarocks init` for per-project workflows [1]
- New flags, including `--lua-dir` and `--lua-version` for using
multiple Lua installs with a single LuaRocks
- New build system, gearing towards a new distribution model [2]
- General improvements, including namespaces [3]
- User-visible changes, including some breaking changes
- Internal changes

All of the above are detailed here:

* https://github.com/luarocks/luarocks/blob/master/CHANGELOG.md

I'll try to write up more documentation between now and the final
release. Feedback is wanted regarding what needs to be
documented/explained! And help updating the wiki is especially
welcome.

And without further ado, the tarball for Unix is here:

https://luarocks.github.io/luarocks/releases/luarocks-3.0.0beta1.tar.gz

This release contains new code by Thijs Schreijer, George Roman, Peter
Melnichenko, Kim Alvefur, Alec Larson, Evgeny Shulgin, Michal Cichra,
Daniel Hahler, and myself.

Very special thanks to my employer Kong, for sponsoring my work on
LuaRocks over the last year and making this release possible. Thanks
also to my colleagues Aapo Talvensaari and Enrique García Cota for
helping out with some last-minute testing.

In the name of everyone in the LuaRocks development team, thank you
for the continued amazing support that Lua community has been giving
LuaRocks over the years: keep on rockin'!

Cheers!!!

Hisham Muhammad
-- LuaRocks lead developer
-- https://luarocks.org

[1] https://github.com/luarocks/luarocks/wiki/Project:-LuaRocks-per-project-workflow
[2] https://github.com/luarocks/luarocks/wiki/Project:-LuaRocks-new-distribution-model
[3] https://github.com/luarocks/luarocks/wiki/Namespaces

Hi Hisham,

I'm working on getting LuaRocks 3.0 into the FreeBSD ports tree. The port Makefile is here: https://reviews.freebsd.org/D16274

I am getting an error trying to build luarocks-admin. Any help would be great.

Thanks! Russ


russellh@g1 ~/f/p/d/lua-luarocks> make
===>  License MIT accepted by the user
===>   lua53-luarocks-3.0.0 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by lua53-luarocks-3.0.0 for building
===>  Extracting for lua53-luarocks-3.0.0
=> SHA256 Checksum OK for luarocks-3.0.0beta2.tar.gz.
===>  Patching for lua53-luarocks-3.0.0
===>   lua53-luarocks-3.0.0 depends on shared library: liblua-5.3.so - found (/usr/local/lib/liblua-5.3.so)
===>  Configuring for lua53-luarocks-3.0.0

Configuring LuaRocks...

Lua interpreter found: /usr/local/bin/lua53
Checking if /usr/local/bin/lua53 is Lua version 5.3... yes
lua.h found: /usr/local/include/lua53/lua.h
unzip found in PATH: /usr/bin

Done configuring.

LuaRocks will be installed at......: /usr/local
LuaRocks will install rocks at.....: /usr/local
LuaRocks configuration directory...: /usr/local/etc/luarocks
Using Lua from.....................: /usr/local
Lua include directory..............: /usr/local/include/lua53

* Type make build and make install:
  to install to /usr/local as usual.
* Type make bootstrap:
  to install LuaRocks into /usr/local as a rock.

===>  Building for lua53-luarocks-3.0.0
make[2]: make[2]: don't know how to make ./luarocks-admin. Stop

make[2]: stopped in /usr/home/russellh/freebsd/ports/devel/lua-luarocks/work/luarocks-3.0.0beta2
===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
the maintainer.
*** Error code 1

Stop.
make[1]: stopped in /usr/home/russellh/freebsd/ports/devel/lua-luarocks
*** Error code 1

Stop.
make: stopped in /usr/home/russellh/freebsd/ports/devel/lua-luarocks
russellh@g1 ~/f/p/d/lua-luarocks>


The following patch lets me build LuaRocks from the tarball:

root@beaglebone:/home/freebsd/luarocks-3.0.0beta2 # diff -u Makefile Makefile.orig
--- Makefile    2018-07-14 11:00:29.219948000 -0700
+++ Makefile.orig       2018-07-14 11:00:19.028491000 -0700
@@ -1,7 +1,7 @@

 -include config.unix

-all: ./luarocks luarocks-admin
+all: ./luarocks ./luarocks-admin

 # ----------------------------------------
 # Base build
root@beaglebone:/home/freebsd/luarocks-3.0.0beta2 # diff -u Makefile.orig Makefile
--- Makefile.orig       2018-07-14 11:00:19.028491000 -0700
+++ Makefile    2018-07-14 11:00:29.219948000 -0700
@@ -1,7 +1,7 @@

 -include config.unix

-all: ./luarocks ./luarocks-admin
+all: ./luarocks luarocks-admin

 # ----------------------------------------
 # Base build

 
root@beaglebone:/home/freebsd/luarocks-3.0.0beta2 # uname -a
FreeBSD beaglebone 11.2-RELEASE FreeBSD 11.2-RELEASE #0 r335510: Fri Jun 22 02:27:16 UTC 2018     [hidden email]:/usr/obj/arm.armv6/usr/src/sys/BEAGLEBONE  arm
root@beaglebone:/home/freebsd/luarocks-3.0.0beta2 # luarocks help
Warning: The directory '/root/.cache/luarocks' or its parent directory is not owned by the current user and the cache has been disabled. Please check the permissions and owner of that directory. If executing /usr/local/bin/luarocks with sudo, you may want sudo's -H flag.

LuaRocks 3.0.0beta2, the Lua package manager
...

Sweet! I'll have to figure out the ports stuff later. 
Cheers,
Russ

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] LuaRocks 3.0.0beta1 for Unix

Russell Haley

On Sat, Jul 14, 2018 at 11:06 PM, Russell Haley <[hidden email]> wrote:


On Sat, Jul 14, 2018 at 9:29 PM, Russell Haley <[hidden email]> wrote:


On Wed, Jul 4, 2018 at 3:36 PM, Hisham <[hidden email]> wrote:
Hello list,

I am extremely happy to announce LuaRocks 3.0.0beta1, the
almost-finished package for the new major release of LuaRocks, the Lua
package manager.

***
First of all: "Why beta1?" — the code itself is release-candidate
quality, but I decided to call this one beta1 and not rc1 because the
Windows package is not ready yet, and I wanted to get some early
feedback on the Unix build while I complete the final touches of the
Windows package.

This is NOT going to be a long-or-endless beta cycle: if no major
showstoppers are reported, the final 3.0.0 release, including Unix and
Windows packages, is expected to arrive in one week. But please, if
you want to help out with LuaRocks, give this beta1 a try and report
any findings!
***

Yes, it's finally here! After a way-too-long gestation period,
LuaRocks 3 is about ready to see the light of day. And it includes a
lot of new stuff:

- New rockspec format
- New commands, including `luarocks init` for per-project workflows [1]
- New flags, including `--lua-dir` and `--lua-version` for using
multiple Lua installs with a single LuaRocks
- New build system, gearing towards a new distribution model [2]
- General improvements, including namespaces [3]
- User-visible changes, including some breaking changes
- Internal changes

All of the above are detailed here:

* https://github.com/luarocks/luarocks/blob/master/CHANGELOG.md

I'll try to write up more documentation between now and the final
release. Feedback is wanted regarding what needs to be
documented/explained! And help updating the wiki is especially
welcome.

And without further ado, the tarball for Unix is here:

https://luarocks.github.io/luarocks/releases/luarocks-3.0.0beta1.tar.gz

This release contains new code by Thijs Schreijer, George Roman, Peter
Melnichenko, Kim Alvefur, Alec Larson, Evgeny Shulgin, Michal Cichra,
Daniel Hahler, and myself.

Very special thanks to my employer Kong, for sponsoring my work on
LuaRocks over the last year and making this release possible. Thanks
also to my colleagues Aapo Talvensaari and Enrique García Cota for
helping out with some last-minute testing.

In the name of everyone in the LuaRocks development team, thank you
for the continued amazing support that Lua community has been giving
LuaRocks over the years: keep on rockin'!

Cheers!!!

Hisham Muhammad
-- LuaRocks lead developer
-- https://luarocks.org

[1] https://github.com/luarocks/luarocks/wiki/Project:-LuaRocks-per-project-workflow
[2] https://github.com/luarocks/luarocks/wiki/Project:-LuaRocks-new-distribution-model
[3] https://github.com/luarocks/luarocks/wiki/Namespaces

Hi Hisham,

I'm working on getting LuaRocks 3.0 into the FreeBSD ports tree. The port Makefile is here: https://reviews.freebsd.org/D16274

I am getting an error trying to build luarocks-admin. Any help would be great.

Thanks! Russ


russellh@g1 ~/f/p/d/lua-luarocks> make
===>  License MIT accepted by the user
===>   lua53-luarocks-3.0.0 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by lua53-luarocks-3.0.0 for building
===>  Extracting for lua53-luarocks-3.0.0
=> SHA256 Checksum OK for luarocks-3.0.0beta2.tar.gz.
===>  Patching for lua53-luarocks-3.0.0
===>   lua53-luarocks-3.0.0 depends on shared library: liblua-5.3.so - found (/usr/local/lib/liblua-5.3.so)
===>  Configuring for lua53-luarocks-3.0.0

Configuring LuaRocks...

Lua interpreter found: /usr/local/bin/lua53
Checking if /usr/local/bin/lua53 is Lua version 5.3... yes
lua.h found: /usr/local/include/lua53/lua.h
unzip found in PATH: /usr/bin

Done configuring.

LuaRocks will be installed at......: /usr/local
LuaRocks will install rocks at.....: /usr/local
LuaRocks configuration directory...: /usr/local/etc/luarocks
Using Lua from.....................: /usr/local
Lua include directory..............: /usr/local/include/lua53

* Type make build and make install:
  to install to /usr/local as usual.
* Type make bootstrap:
  to install LuaRocks into /usr/local as a rock.

===>  Building for lua53-luarocks-3.0.0
make[2]: make[2]: don't know how to make ./luarocks-admin. Stop

make[2]: stopped in /usr/home/russellh/freebsd/ports/devel/lua-luarocks/work/luarocks-3.0.0beta2
===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
the maintainer.
*** Error code 1

Stop.
make[1]: stopped in /usr/home/russellh/freebsd/ports/devel/lua-luarocks
*** Error code 1

Stop.
make: stopped in /usr/home/russellh/freebsd/ports/devel/lua-luarocks
russellh@g1 ~/f/p/d/lua-luarocks>


The following patch lets me build LuaRocks from the tarball:

root@beaglebone:/home/freebsd/luarocks-3.0.0beta2 # diff -u Makefile Makefile.orig
--- Makefile    2018-07-14 11:00:29.219948000 -0700
+++ Makefile.orig       2018-07-14 11:00:19.028491000 -0700
@@ -1,7 +1,7 @@

 -include config.unix

-all: ./luarocks luarocks-admin
+all: ./luarocks ./luarocks-admin

 # ----------------------------------------
 # Base build
root@beaglebone:/home/freebsd/luarocks-3.0.0beta2 # diff -u Makefile.orig Makefile
--- Makefile.orig       2018-07-14 11:00:19.028491000 -0700
+++ Makefile    2018-07-14 11:00:29.219948000 -0700
@@ -1,7 +1,7 @@

 -include config.unix

-all: ./luarocks ./luarocks-admin
+all: ./luarocks luarocks-admin

 # ----------------------------------------
 # Base build

 
root@beaglebone:/home/freebsd/luarocks-3.0.0beta2 # uname -a
FreeBSD beaglebone 11.2-RELEASE FreeBSD 11.2-RELEASE #0 r335510: Fri Jun 22 02:27:16 UTC 2018     [hidden email]:/usr/obj/arm.armv6/usr/src/sys/BEAGLEBONE  arm
root@beaglebone:/home/freebsd/luarocks-3.0.0beta2 # luarocks help
Warning: The directory '/root/.cache/luarocks' or its parent directory is not owned by the current user and the cache has been disabled. Please check the permissions and owner of that directory. If executing /usr/local/bin/luarocks with sudo, you may want sudo's -H flag.

LuaRocks 3.0.0beta2, the Lua package manager
...

Sweet! I'll have to figure out the ports stuff later. 
Cheers,
Russ


Hi, so I got the port file to work and noticed some anomalies that slipped past me last night. I've put my console output of a "plain tarball build" (compared to building via the external ports Makefile)  here: https://pastebin.com/Mr91T9UT

1) ./configure doesn't find the default include directory on FreeBSD. (The port Makefile passes the value in, but it would be nice to see it patched upstream to use /usr/local/include/lua5X/)
2) There is a mistake in the help output --with-include should be --with-lua-include
3) I need to run the build command twice... ? I'm not sure what's up with that. It's the same in a tarball build and a ports build.

I'm very keen to see LuaRocks maintained in FreeBSD so we can perhaps leverage it in the standard build process for packages that rely on Lua. I don't know if the idea would fly, but that's what I would like to push for. 

Cheers, 

Russ