lua 5.4.1

[chenrui333]

Created with brew bump-formula-pr.

[gromgit]

Shouldn't the test block do an assert_match instead of just printing a test string?

[chenrui333]

Shouldn't the test block do an assert_match instead of just printing a test string?

I was literally thinking the same thing just now :D

I will update that.

[chenrui333]

Should be good now.

[chenrui333]

10.13

Error: 17 failed steps!
brew test --verbose luarocks
brew install --verbose --build-bottle corsixth
brew install --verbose --build-bottle instead
brew install --verbose --build-bottle kyoto-tycoon
brew install --verbose --build-bottle lmod
brew audit --skip-style lmod --online --git
brew install --verbose --build-bottle lsyncd
brew install --verbose --build-bottle macvim
brew install --verbose --build-bottle mame
brew install --verbose --build-bottle neomutt
brew install --verbose --build-bottle osrm-backend
brew audit --skip-style pdns --online --git
brew install --verbose --build-bottle pdnsrec
brew install --verbose --build-bottle sile
brew audit --skip-style tracebox --online --git
brew install --verbose --build-bottle vim
brew install --verbose --build-bottle vis

10.14

Error: 18 failed steps!
brew test --verbose luarocks
brew install --verbose --build-bottle corsixth
brew install --verbose --build-bottle instead
brew install --verbose --build-bottle kyoto-tycoon
brew install --verbose --build-bottle lmod
brew audit --skip-style lmod --online --git
brew install --verbose --build-bottle lsyncd
brew install --verbose --build-bottle macvim
brew install --verbose --build-bottle mame
brew install --verbose --build-bottle neomutt
brew install --verbose --build-bottle osrm-backend
brew audit --skip-style pdns --online --git
brew install --verbose --build-bottle pdnsrec
brew install --verbose --build-bottle sile
brew install --verbose --build-bottle tracebox
brew audit --skip-style tracebox --online --git
brew install --verbose --build-bottle vim
brew install --verbose --build-bottle vis
##[error]Process completed with exit code 1.

10.15

Error: 19 failed steps!
brew test --verbose luarocks
brew install --verbose --build-bottle corsixth
brew install --verbose --build-bottle instead
brew install --verbose --build-bottle kyoto-tycoon
brew install --verbose --build-bottle lmod
brew audit --skip-style lmod --online --git
brew fetch --retry lsyncd --build-bottle --force
brew install --verbose --build-bottle lsyncd
brew install --verbose --build-bottle macvim
brew install --verbose --build-bottle mame
brew install --verbose --build-bottle neomutt
brew install --verbose --build-bottle osrm-backend
brew audit --skip-style pdns --online --git
brew install --verbose --build-bottle pdnsrec
brew install --verbose --build-bottle sile
brew install --verbose --build-bottle tracebox
brew audit --skip-style tracebox --online --git
brew install --verbose --build-bottle vim
brew install --verbose --build-bottle vis

[chenrui333]

rebased to latest master and fixed the merge conflict with vim

[alebcay]

Looks like solaris is still missing here - does it need to be added back?

[chenrui333]

This won't impact the git patch. (more just like reference line)

[alerque]

Lua 5.4 support for SILE is ready to go upstream (tracking issue, pending PR), but it's held up being released until there is a published version of lua-zlib that works (tracking issue). I'll be sure to cut a release as soon as that's available, at which point SILE won't be a hold up for Homebrew switching to Lua 5.4!

[alerque]

As of v0.10.9 SILE supports Lua 5.4 (Homebrew PR here). After that is merged the formula can be updated to use Lua 5.4 at any time. Note some of the LuaRocks being installed are being built from the Github tagged versions. Several projects have released new Rocks on LuaRocks by bumping the rockrel without tagging a release on Github. For every project where that is the case the upper bound restriction can just be removed from the rockspec before building. If you want me to submit a patch with `sed command to take care of that universally for that formula I can.

[chenrui333]

Going to refresh this PR now.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[alerque]

Oh stow it @Stale, Rome wasn't built in a day.

[chenrui333]

Oh stow it @Stale, Rome wasn't built in a day.

😄

[carlocab]

I tried opening a PR to try to update lua, but I can now see that that's not going to work.

Would the following work?

1. Add a [email protected] formula in a separate PR (lua 5.3.6 #65979)
2. When the previous is merged, any formulae causing test failures here can have their dependency changed to [email protected] so this PR can be merged.
3. Try to bump the formulae that had to depend on [email protected] to [email protected] in separate PRs.

[fxcoudert]

@carlocab all formulas that are not currently working with lug 5.4 need to be investigated: is upstream aware of the issue, when is a fix planned, etc. We don't want to migrate formulas to an older version if they are not going to be migrated over time to something more recent

[carlocab]

Thanks @fxcoudert. I'm aware of that. That's what step 3 in my last comment was for. (We can even open a tracking issue for it...)

I'm just thinking it makes more sense to migrate all the formulae that get stuck on [email protected] slowly individually, rather than have them block the upgrade to lua like they're doing in this PR.

I think my suggestion to migrate formulae separately rather all in one big PR also benefits from allowing the community to pitch in more with the migration. Right now it's really only those with write access who can try fixes for the build failures, and I think that needlessly adds to the burden on maintainers.

I would also like to point out that different versions of lua aren't quite like different versions of other packages. Here's Neovim's lead maintainer on the subject:

Lua 5.1 is a different, complete language than Lua 5.3. Lua 5.3 is not an "upgrade" to Lua 5.1, it's a different language.

neovim/neovim#9760 (comment)

[alerque]

@fxcoudert I hear what you are saying, but I don't think it quite fits the circumstances here. What @carlocab proposed isn't "migrating formulas to and older version" per se, it is holding them on the current version they are using successfully while not holding back other projects that could/should use a new Lua release. Unfortunately the Lua ecosystem is somewhat fragmented and different language VMs have different features. 5.1→5.2→5.3 is not as straightforward a version bump upgrade path as the numbers would lead you to believe. Some projects will require 5.3 for some time yet. Some may never get ported, but that doesn't make them obsolete. There are actively maintained projects out there that still depend on 5.1 language features. This shouldn't by such a road block to updating the default Lua interpreter.

The proposal here to upgrade everything that can be while not needing to hold forever or mass-remove a bunch of working formula makes great sense given the state of the Lua ecosystem. I don't like it either, but I don't manage Lua releases upstream 🤷‍♂️. As a downstream Lua developer quite familiar with different projects' approaches to interpreter versioning I can vouch for the sanity of this idea.

[gromgit]

From https://www.lua.org/versions.html#numbering:

Different versions are really different. The API is likely to be a little different (but with compatibility switches), and there is no ABI compatibility: applications that embed Lua and C libraries for Lua must be recompiled. The virtual machine is also very likely to be different in a new version: Lua programs that have been precompiled for one version will not load in a different version.

The way I read it, applications stick with a specific Lua version to embed, and move only when required. Also, the "top-level" Lua dylib symlinks actually embed the version in their names (liblua5.1.dylib vs. liblua5.3.dylib), just like on every Linux distro I've seen (liblua5.1.so, etc.). Also, AFAIK, only Homebrew specifically creates a liblua.dylib symlink, contrary to every other installation I've seen.

IMO, Lua versions should be treated as completely different entities, as upstream clearly intended, so a saner naming scheme that causes the fewest problems in the long term is lua51, lua53, etc. Since pretty much nothing depends on Lua 5.4 at this point, can I suggest naming this formula lua54 instead, and leaving the other lua formulae alone for now?

(If we take this route, lua54 should not create liblua.dylib, nor any of the other version-neutral links.)

[fxcoudert]

can I suggest naming this formula lua54 instead, and leaving the other lua formulae alone for now?

No, please don't.

We are aware that lua has several versions with differences, and therefore a [email protected] will be accepted in homebrew-core, as that is still maintained. However, we also need to make sure that there is some movement of the other formulas depending on it, otherwise we end up with unmaintainable messes: for example, we still have formulas that depend on [email protected] even though that has been unmaintained for 8 years (last release in Feb 2012);

[fxcoudert]

I'm aware of that. That's what step 3 in my last comment was for. (We can even open a tracking issue for it...)

@carlocab excellent then. Only thing is: this cannot be done in separate PRs, it needs to be the same PR that moves lua to 5.4, creates a [email protected], rebuilds the formulas that build against 5.4, and migrate the other ones to 5.3

I only wish to make sure, before we accept that, that all formulas that are "stuck" on 5.3 have been notified, and we add a link to the upstream tracking issue above the dependency in the formula. That way, we can check we when update them, if support for latest lua is available.

[carlocab]

excellent then. Only thing is: this cannot be done in separate PRs, it needs to be the same PR that moves lua to 5.4, creates a [email protected], rebuilds the formulas that build against 5.4, and migrate the other ones to 5.3

I may have expressed myself poorly then because this is exactly what I meant. Apologies for the miscommunication.

To be clear, step 3 was meant to handle the formulae that get stuck with [email protected] from this PR. That is, by "separate PRs", I meant other PRs that work on upgrading dependencies from [email protected] to lua[@5.4].

[fxcoudert]

Merged in #65993