Can some of these be migrated to one of the lua formulas?

In theory, it should be possible to migrate them to [email protected]. That would, however, almost certainly cause performance regressions.

For reference, a number of other package managers actually ship 2.1.0-beta3, including Debian Stable and Ubuntu. https://repology.org/project/luajit/versions

https://repology.org/project/luajit/versions indicates that there is apparently a 2.1.0-beta3? If there is a problem migrating to [email protected] we could choose to allow this beta.

2.1.0-beta3 is from 2017, it would still need to be patched to build

If we are deprecating luajit, we should also pick a date to disable it (absent a change of circumstances). I don't want to give users the impression that a deprecation warning is something that can be ignored indefinitely.

There are (and have been) a lot of LuaJIT forks. I've been looking at the OpenResty fork which seems to be consistently active. A fair amount of upstreams support just LuaJIT so replacing with a fork if possible will be best.

I'm interested if anyone has any views on other forks which look sustainable. The original LuaJIT isn't actually dead either, it's just.. not making releases for quite some time.

(We are having similar discussions in Gentoo).

@carlocab I can confirm this is deprecated as well. Running brew uses [email protected] on my machine returns the following list:

gnuplot@4 libswiften mpv wireshark libquvi luabind stone-soup

YMMV, but this is just what I found when the warning appeared after invoking brew doctor.

@chrisfinazzo I'm aware. I merged the PR deprecating [email protected] about a week ago.

Opened #68787. Let's see if this works. Thanks for the suggestion, @thesamesam.

Speaking for neovim: this project heavily leverages LuaJIT, so replacing that with PUC Lua would be a significant performance regression. The last beta release (2.1.0-beta3) does not support Apple ARM, so it was necessary to switch to a post-release git commit (and adapt some tests and plugins to the breaking changes therein) for master (that is to become 0.5 soon(tm)). There have been requests to backport these changes to the 0.4 release branch. I don't think any of the forks (OpenResty, MoonJIT) are drop-in replacements, either.

It is very unfortunate that LuaJIT refuses to just release a beta4. If that means LuaJIT is removed from homebrew, it would probably be necessary to adapt the build scripts to let neovim pull in and build its own version of LuaJIT (like it does for the manual build).

That would violate https://docs.brew.sh/Acceptable-Formulae#we-dont-like-install-scripts-that-download-unversioned-things so it would be more likely we would have to live with the performance regression.

@SMillerDev are you sure? to me it sounds like only unspecficied versions are banned, not if the scripts points to choosen known good commit with a checksum.

I don’t think it violates that rule, actually. I think @clason just means that the neovim formula would add its own luajit resource, which would be a versioned dependency.

That said, it looks to me like the OpenResty fork could be a drop-in replacement... It also supports Apple ARM. See the PR I opened. I’ll try using it to build Neovim later today.

I don’t think it violates that rule, actually. I think @clason just means that the neovim formula would add its own luajit resource, which would be a versioned dependency.

Might be okay then, even though I'd prefer to depend on a known good, working formula (lua) then installing a resource because upstream doesn't want to make their work packagable

I dunno; trying to switch out a dependency that upstream have specified as what works for them sounds to me as very much like heavy patching of a formula. We don’t like patches; we probably shouldn’t like this either.

Even if neovim itself only uses PuC lua5.1 api, many plugins depend on luajit either explicitly or implicitly (optimizing for an acceptable user experience only with jit enabled). PuC lua fallback is meant more for niche platforms ( a slow neovim is better than no neovim on your MIPS router), not for major platforms and especially not a flagship product that is marketed primarily for speed and battery life (M1 mac).

Tried building neovim, both release and HEAD against the latest tagged release of OpenResty LuaJIT. In both cases, it starts up perfectly fine and :checkhealth reveals no problems. (As mentioned, the latest LuaJIT release doesn't actually work for a HEAD neovim build. Cf. neovim/neovim#13529)

I'm going to put it on my tap for anyone who wants to test it (carlocab/homebrew-personal#27), but it's still building on GitHub runners at the moment. If you don't want to wait you can always check out the appropriate branch and build from there.

Update: Finally got off the GitHub runner queue, so I've merged the PR above. You can try Neovim built against OpenResty LuaJIT by

brew tap carlocab/personal
brew install neovim-openresty

neovim-openresty is keg-only, so you'll need to either add it to your PATH or call it using something like $(brew --prefix neovim-openresty)/bin/nvim.

I'll give it a whirl later (on Intel) with a non-trivial actual use of Lua plugins.

Seems to work well in preliminary tests (HEAD, playing with packer, treesitter, LSP, telescope)!

@carlocab : It looks like this has been discussed and is fixed. I guess you could close this issue.