Page MenuHomeFreeBSD

Add `flavors` support to devel/lua-luarocks
ClosedPublic

Authored by russ.haley_gmail.com on Jul 23 2020, 6:48 AM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Dec 13, 3:51 AM
Unknown Object (File)
Mon, Dec 9, 3:30 AM
Unknown Object (File)
Fri, Dec 6, 12:49 PM
Unknown Object (File)
Thu, Nov 28, 2:04 AM
Unknown Object (File)
Nov 23 2024, 1:01 PM
Unknown Object (File)
Nov 12 2024, 10:16 PM
Unknown Object (File)
Nov 9 2024, 9:54 PM
Unknown Object (File)
Nov 9 2024, 3:26 PM
Subscribers

Details

Summary

Hello sunpoet! Thank you very much for pushing LuaRocks forward.

Here is some background about this patch:

  • Lua.org has now released Lua 5.4.0. There is a review for the lua54 port here: https://reviews.freebsd.org/D14709
  • Andrew Gierth has added flavors support to the Lua toolchain through Mk/Uses/lua.mk. flavors support allows a user to build lua tools against any version of Lua that the tool supports.

This patch adds Lua flavor support to the LuaRocks package manager so we don't have to be stuck at 5.2 anymore. To use flavors to build LuaRocks against a specific version of Lua:

make FLAVOR=lua53

Thank you for your time and for considering this patch.

Regards,
Russell

Test Plan

Tested on FreeBSD 12.1 STABLE.

Ran make and the system built lua52 (system default)
Running make FLAVOR=lua54 creates luarocks54 that correctly links to the Lua54 port I am testing.

Diff Detail

Repository
rP FreeBSD ports repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

This needs to get a PORTREVISION bump.

Also, could you please use devel/arcanist to create/update reviews, or at least, create a diff with full context as it does. (Using svn diff -x -U9999 or git diff -U9999.)

What's the justification for adding flavors, given that one luarocks install is supposed to be able to manage multiple lua versions?

I think, in fact, the only useful change would be to install config files for every supported lua version rather than just the default one.

What's the justification for adding flavors, given that one luarocks install is supposed to be able to manage multiple lua versions?

When I try installing LuaRocks from ports/pkg I always get 5.2, regardless of the installed version of lua (due to the FreeBSD default Lua version of 5.2). The FreeBSD default means Luarocks is also configured for Lua 5.2 and the executable/script is called luarocks52. Perhaps I've done something wrong and there is an easier way around that, but this seems to perfectly fit the use case for flavors?

With flavors I can now run make FLAVOR=lua54 install and get what I want: luarocks53 and luarocks54. I also guess/wonder/postulate that the lua-luarocks port could be configured to allow for pkg installations of luarocks5x (e.g. sudo pkg install lua54 luarocks54)?

So far in my testing, everything is working well. I am testing with lua52, lua53 and lua54. As expected I can install rocks in each and the modules load through require().

In D25784#570923, @mat wrote:

This needs to get a PORTREVISION bump.

Also, could you please use devel/arcanist to create/update reviews, or at least, create a diff with full context as it does. (Using svn diff -x -U9999 or git diff -U9999.)

Thanks Mat, I couldn't remember the correct options for svn.

Added PORTREVISION. Corrected diff format.

What's the justification for adding flavors, given that one luarocks install is supposed to be able to manage multiple lua versions?

When I try installing LuaRocks from ports/pkg I always get 5.2, regardless of the installed version of lua (due to the FreeBSD default Lua version of 5.2). The FreeBSD default means Luarocks is also configured for Lua 5.2 and the executable/script is called luarocks52. Perhaps I've done something wrong and there is an easier way around that, but this seems to perfectly fit the use case for flavors?

Luarocks has a --lua-version option that allows one copy of luarocks to manage rocks trees for multiple versions of Lua regardless of what version it itself uses. Therefore flavors are neither necessary nor desirable.

It would make more sense to simply stop using UNIQUE_SUFFIX_FILES and include multiple versions of the config file.

This revision now requires changes to proceed.Jul 24 2020, 11:58 AM

What's the justification for adding flavors, given that one luarocks install is supposed to be able to manage multiple lua versions?

When I try installing LuaRocks from ports/pkg I always get 5.2, regardless of the installed version of lua (due to the FreeBSD default Lua version of 5.2). The FreeBSD default means Luarocks is also configured for Lua 5.2 and the executable/script is called luarocks52. Perhaps I've done something wrong and there is an easier way around that, but this seems to perfectly fit the use case for flavors?

Luarocks has a --lua-version option that allows one copy of luarocks to manage rocks trees for multiple versions of Lua regardless of what version it itself uses. Therefore flavors are neither necessary nor desirable.

I have never used that option on any of the three platforms on which I use LuaRocks. Moreover, there is no way currently to generate config files (outside of installation) so a user must manually copy and modify the existing one (I agree that replicating configs is a simple task for an experienced user). I have a "feature request" with the LuaRocks team for a feature to create config files.

In my typical usage(s) of the LuaRocks installation, the makefile configures against the highest Lua version found on the system. Unless the person is actively using an old version of Lua, one would never have used that option and it is not advertised in the standard luarocks patterns (e.g. new users wouldn't know about that). Conversly, people that DO use more than one version of Lua would have actively used the LUA_VERSION option in the LuaRocks install and would be aware of the adjustments needed to support multiple versions of Lua/LuaRocks. It would be fair to say that --lua-version is an "advanced" feature.

It would make more sense to simply stop using UNIQUE_SUFFIX_FILES and include multiple versions of the config file.

The manual nature of LuaRocks config files and the 9 year old default settings in FreeBSD make this undesirable. UNIQUE_SUFFIX_FILES is the pattern that FreeBSD uses for other languages and package managers.

My arguments is this:

As of now if a user wanted to deploy luarocks for 5.3 without flavors they would need to:

  • Install lua53
  • Fight with the OS because they can only get luarocks52 to install. *IMHO, at this point 99% of people new to FreeBSD or Lua are going to give up and install Python.
  • Somehow not give up and come across this obscure information that not only is FreeBSD different than Linux and Windows because we use version suffixes, but there is an exception to the version suffix pattern for LuaRocks. Again, all other languages, package managers and tools I have come across use the VERSION_SUFFIX pattern in FreeBSD. Ask yourself, Why has this person not given up and just installed luarocks manually? That's what I have have been doing for the past several years becuase I don't have an option like Flavors!
  • Now, after a huge amount of pain and agony they must manually create a luarocks config file. To auto generate a file you would need to download the luarocks package.
  • Finally, after all those problems the person would need to type luarocks --lua-version 5.x for EVERY SINGLE LUAROCKS CALL. I would think that person would manually create a shell script. One might even call that shell script luarock53. ;)

I argue that flavors is exactly the correct tool to solve the aforementioned problems and fits the UNIQUE_SUFFIX_FILES pattern perfectly. The downsides of installing more than one copy of the LuaRocks scripts are negligible. The files are only a few MB in size so that isn't a factor. Each installation will be properly indicated by pkg and so would be upgraded the same as other packages mooting any upgrade issues. And in a fit of hopeful speculation I wonder if pkg can pick up the different flavors? Installations then become pkg install lua-luarocks53 if this is possible.

The positives of the UNIQUE_SUFFIX_FILES method are that LuaRocks fits the FreeBSD suffix pattern the same as all other tools, each Lua installation has it's own unique set of scripts so they can be easily added and removed, the configuration files and shell script wrappers are provided by the upstream package during installation and ports does what it is supposed to do and provides easy access to an application/tool for FreeBSD.

The ports collection is supposed to ease the *configuration* and usage of FOSS software on FreeBSD. Adding flavors to support UNIQUE_SUFFIX_FILES is the correct way to achieve this end.

Thanks Andrew!

I still think it's nuts to install multiple luarocks installations when the big feature of luarocks 3.x was the ability to handle multiple lua versions. But I'll withdraw my objection.

And in a fit of hopeful speculation I wonder if pkg can pick up the different flavors? Installations then become pkg install lua-luarocks53 if this is possible.

Adding flavors will cause all of lua51-luarocks, lua52-luarocks, lua53-luarocks, and (when lua54 is committed) lua54-luarocks to be built as separate packages.

(It is lua53-luarocks and not lua-luarocks53 for consistency with every other package, the convention for all language-version flavors is to use them as a prefix.)

But there's another issue that needs fixing here, which is that you're breaking the luajit option. The lua:flavors option has to go on the LUAJIT_USES_OFF line, not the USES line, because lua flavors don't work with luajit (which is forced to be 5.1). Better integration of luajit is something I've so far failed to work out a good solution for; luajit really ought to be its own flavor, but there are too many conflicts between that and stock lua 5.1.

I

I still think it's nuts to install multiple luarocks installations when the big feature of luarocks 3.x was the ability to handle multiple lua versions. But I'll withdraw my objection.

And in a fit of hopeful speculation I wonder if pkg can pick up the different flavors? Installations then become pkg install lua-luarocks53 if this is possible.

Adding flavors will cause all of lua51-luarocks, lua52-luarocks, lua53-luarocks, and (when lua54 is committed) lua54-luarocks to be built as separate packages.

(It is lua53-luarocks and not lua-luarocks53 for consistency with every other package, the convention for all language-version flavors is to use them as a prefix.)

But there's another issue that needs fixing here, which is that you're breaking the luajit option. The lua:flavors option has to go on the LUAJIT_USES_OFF line, not the USES line, because lua flavors don't work with luajit (which is forced to be 5.1). Better integration of luajit is something I've so far failed to work out a good solution for; luajit really ought to be its own flavor, but there are too many conflicts between that and stock lua 5.1.

You seem to be stuck between a luarock and a hard place... :)

Move lua:flavors from USES to LUAJIT_USES_OFF as per comments.

This revision is now accepted and ready to land.Jul 25 2020, 6:05 AM
This revision was automatically updated to reflect the committed changes.