Different Lua version in shell, in type hints and at runtime

Problem description

The type hint for _VERSION says it’s "Lua 5.4":

(global) _VERSION: string = "Lua 5.4"

Yet the shell says it’s 5.2:

$ lua -v / Lua 5.2.4

That shell’s Repl config doesn’t have a version:

{ pkgs }: {
  deps = [

The shell of another Repl which was created earlier says 5.4:

$ lua -v / Lua 5.4.4

…and it has 5.4 in its replit.nix (adding pkgs.lua5_4_compat to the other Repl does make the shell use 5.4):

{ pkgs }: {
  deps = [

…while the Repls themselves output 5.1 when being run:

Expected behavior
One single version 5.4 everywhere.

Steps to reproduce

I don’t think this is browser/OS-dependent.

This is not a bug, this is simply the version installed as per the Nix module used. If you go to nixos.org, and search for a package you will see which version it is, the version-less named package is almost never the latest version.

This is not a bug

Maybe it’s not a bug per se, but it confused the hell out of me when I tried some 5.2+ features just to be told that nil is not callable, being reassured by both the type hints and the shell just a second before that.

Bug or not, there’s still something wrong about it, no?

1 Like

It turns out this is due to Prybar which only support Lua 5.1. I managed to get it work by removing the [interpreter] section and add the run field:

run = "lua main.lua"

While painstakingly trying to figure what arguments to remove from interpreter.command (which was, of course, not the correct way), I found out that this is the absolute minimum prybar-lua command that will run fine:

command = [

…where --ps1 means setting the prompt text and -iinteractive (use language repl)”, according to replit/prybar/README.md. The Repl refuses to run correctly with a prompt text not containing that unprintable character (or, much more understandably, without -i).

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.