Lua 5.2 -> 5.3

[daurnimator]

Lua 5.3 came out this morning, lets get it available from homebrew :)

Related issue: #32354

If everything currently using Lua-5.2 happily transitions to Lua-5.3 then it's likely we'll shove Lua-5.1 out of the core (Into Homebrew/Versions) and start maintaining a Lua and a Lua52, but if adoption rates are slow it is likely that Lua53 will start out in Homebrew/Versions and work its way towards the core as adoption progresses.

[asparagui]

ping @DomT4

[DomT4]

This is going to be hell, heh. I'll locally compile Lua53 later tonight and see what conflict already exists, and how much we can do about it.

@MikeMcQuaid, @jacknagel, @tdsmith, @mistydemeo, Adam & Brett, any strong feelings about how you want to handle this? I presume we don't want to maintain three different Lua versions in Homebrew/Homebrew, so I guess the answer is to either move Lua51 to Homebrew/Versions and support Lua52 and Lua53 with Lua52 = Lua, or to move Lua53 into Homebrew/Versions until there's wider support there from our formulae. I'll run a bunch of the Lua52 dependency stuff against the new Lua53 tonight, but I'm not expecting miracles, sadly.

There's only a couple of remaining deps on Lua51 in the core. We managed a decent migration there, so theoretically, moving that away wouldn't be too odious if necessary.

[MikeMcQuaid]

Really I'd like to only maintain one version in core. Lua 5.3 should live in homebrew-versions until the majority of our Lua packages are ready to be moved over.

[iggyvolz]

I've got a pull request up at homebrew/homebrew-versions#619 to add lua53 over there. Still needs some work to be put up (mirror needs to be added if possible and patches need to be verified)

[DomT4]

What happens with that if someone installs Lua52 or Lua51 alongside that formula?

[iggyvolz]

I commented out the symlinking part so it will only install as lua53. Not sure how that should be handled in transition.

[tdsmith]

Will we allow formulas in core to have an optional dependency on versions/lua53? Letting stuff that embeds lua use lua53 is probably important.

I'd like to have a mechanism for supporting luarocks with lua53, too.

[DomT4]

Will we allow formulas in core to have an optional dependency on versions/lua53?

We generally permit optional deps on taps, so I guess so?

I'd like to have a mechanism for supporting luarocks with lua53, too.

I don't really want to open this flood-gate again, tbh. We've been consistently 👎 on making the Luarocks formula complicated again for the last 4/5 months or so, to the point that we only support it with Lua52 now, and not luajit or lua51 or lua53, etc. I kinda feel like opening that gate again is going to see us face calls to reverse the Luarocks policy, and we'd have no real ground to stand on if we said Lua52 and Lua53 but not Luajit or Lua51. Pretty bleh on the implications of making Luarocks complicated to maintain again.

[DomT4]

I commented out the symlinking part so it will only install as lua53. Not sure how that should be handled in transition.

Won't this mean it installs as Lua? Unless they've changed the default behaviour around their naming?

[tdsmith]

I hear you re: adding complexity to the luarocks formula but I wonder what the point of carrying lua53 at all is, when nothing in Homebrew depends on it, if we're not committed to making it useful for lua developers.

We've had people asking about luarocks support on lua51 in IRC. I understand there are other factors to consider but I think the way we manage luarocks has been a net negative for lua devs's experiences with Homebrew.

If we can start bundling luarocks like pip or like npm, maybe that's simpler.

[DomT4]

I think the way we manage luarocks has been a net negative for lua devs's experiences with Homebrew.

Well, to be honest, we've been trying to get the Lua community to roll their own dedicated tap for a while now, to deal with the complicated dance around symlinking and multiple luarocks trees. If anyone is in a position to massively transform the way we handle Lua, It is the community that uses it most. I don't think there's a huge amount of appetite from maintainers to maintain things that the communities themselves could handle in a way that's more specifically useful to them. The stuff in the core is more catered to the widest user-base possible, whilst not making formulae impossibly difficult to maintain for casual contributors.

I guess there's a whole discussion around what is Homebrew to be had here, who it's designed to appeal to, etc. That's probably a discussion for another time/place.

If we can start bundling luarocks like pip or like npm, maybe that's simpler.

It's not simpler, really. It's not a step I'm opposed to, and it's actually something I've wanted to ponder over for a while, but it's not a particularly simple transition, and it would involve boneyarding the actual luarocks formula and then inserting it into the Lua formulae and then doing a series of revisions. I'm not opposed, but it wouldn't be a simple thing to get done.

[daurnimator]

What is the complexity with the luarocks formula? On my debian and arch systems it lives in harmony.

[DomT4]

Don't Debian and Ubuntu ship Luarocks natively with Lua51? And Arch has two separate Luarocks5.1 and Luarocks5.2 packages?

[daurnimator]

Don't Debian and Ubuntu ship Luarocks natively with Lua51?

No, It is a seperate package.

Arch has two separate Luarocks5.1 and Luarocks5.2 packages?

Yes. Though interestingly enough, they have the same contents in different directories.
You can actually run lua5.2 $(which luarocks-5.1) and get correct behaviour for 5.2 :)

If you can manage this correctly, you can have a single luarocks installation shared by all versions.

[DomT4]

No, It is a seperate package.

Apologies, ship was probably the wrong terminology there. I meant doesn't Luarocks expect to depend on Lua51 on those two systems?

If you can manage this correctly, you can have a single luarocks installation shared by all versions.

To be honest, I personally stress about how prone to breakage this could be. I'd feel more comfortable having different luarocks for each lua formulae, but implementing that wouldn't be a particularly simple step either.

I don't know. I'd like to get more maintainer feedback, and ideally, feedback from the Lua community before we roll anything major on this. Otherwise, at the moment, we roll in one direction for months, and then suddenly switch around and roll in the opposite direction, and I don't think that's a great system for anyone involved.

[MikeMcQuaid]

I hear you re: adding complexity to the luarocks formula but I wonder what the point of carrying lua53 at all is, when nothing in Homebrew depends on it, if we're not committed to making it useful for lua developers.

We do this for a bunch of other things in homebrew-versions. The idea is it's a stepping stone that will allow people to start porting/making things useful. I think it's reasonable for any individual to say "I don't want to do this bit".

If you can manage this correctly, you can have a single luarocks installation shared by all versions.

@daurnimator If you want this you'll need to be the one working on it and submitting pull requests.

[DomT4]

It kinda frustrates me that we can't move Lua51 out of the core at this point, because luabind, mysql-proxy and radare2 have firm deps on it. Everything else that references lua51 does so optionally, so that could continue if Lua51 was shunted to Homebrew/Versions.

I'd be happy having just Lua52 in the core, and Lua51 and Lua53 in versions so things could have an optional dep on those two Luas, but frustratingly, there are a few hold-ups to a single-lua land.

If we can start bundling luarocks like pip or like npm, maybe that's simpler.

Still pondering this though. It's not a bad idea at all.

[gsteemso]

Well, to be honest, we've been trying to get the Lua community to roll their own dedicated tap for a while now, to deal with the complicated dance around symlinking and multiple luarocks trees.

What exactly is involved with that? Does it need to be done by someone “official”?

[DomT4]

@tdsmith maintains a Homebrew/Python tap which is a decent example here. You'd basically just create a repo which was Someone/homebrew-lua, and then people would be able to tap the repo to access the formula.

Doesn't need to be done by anyone official, just someone who's comfortable on a basic level with Ruby, Homebrew and ideally, knows the language involved well.

[iggyvolz]

If anyone really wants to maintain a tap they can but I can volunteer to do it.

[iggyvolz]

Would the tap contain lua.rb (and relating versions) itself or just formulae relating to lua? If the latter then I suppose this is off the original topic.

[DomT4]

Not completely sure. That's a maintainer call. If we look at the Python situation as a comparison, it'd perhaps hint the main/most popular Lua would remain in Homebrew/Homebrew and the rest outsourced to Example/Homebrew-Lua.

[naartjie]

You'd basically just create a repo which was Someone/homebrew-lua, and then people would be able to tap the repo to access the formula.

I started this tap for Luarocks to work with LuaJIT, based on @DomT4 gist, take a look, it might be useful to someone, or we could evolve it to also contain lua51/lua52/lua53/luajit2/luajit2.1.