[thefaux]

> However, when it comes to separating code into modules or packages, Python is more convenient.

Kind of curious about this. I find packaging in Lua quite convenient. I make a file and return either a value or a table full of values and then I require that file in the dependent file that uses the package.

Also, wrt to the missing features like an increment operator. It is possible in at most a few thousand lines of lua to implement a lua' -> lua transpiler where lua' adds some missing features, such as increment operators, in an idiomatic way. In other words, the generated code looks almost exactly the same as the input code except in places where say `x++` gets translated to `x = x + 1`. As long as your file is less than a few thousand lines of code, the transpiler can run in < ~200ms (and obviously much less for shorter files or much faster if the transpiler is implemented in a faster language). Of course the tradeoff is that the original source code may break existing tooling for lua, though the generated code will work fine.

[bmitc]

I don't know Lua, but anyone saying Python's packaging and module story is convenient gives me pause.

[fzil]

makes me think that they haven't used python in a production environment. It's a mess, pip, poetry, stupid eggs.... that's just deployments then there's personal dev environments.

[oefrha]

Guess you never had to fight luarocks then. Everything’s easy when you don’t need to pull in any dependency (which is the case for the most common Lua use cases: host application provides helpers the best they can, you write your own code for everything else). Hell, C’s package management is great if you have nothing to manage.

The first and foremost reason for the complexity of Python’s dependency story is that it’s powerful and people use it a lot.

[wruza]

I’d still take python mess. Rocks feels like early slackware, you can download a rock and maybe it installs, that’s basically it.

[CapsAdmin]

> Kind of curious about this. I find packaging in Lua quite convenient. I make a file and return either a value or a table full of values and then I require that file in the dependent file that uses the package.

While that aspect of it is nice, I think the way paths are handled by default can get annoying.

Since everything has to be relative from the current directory, it's not very convenient to move files around or make a contained module that depend on its own module.

If you're in charge of your own environment, sure, you can roll your own thing, but then you deviate from the norm and your code becomes less portable.

There is also the LuaRocks package manager, which I believe is decent, but it's largely ignored by a big portion of the Lua community.

[spc476]

> Since everything has to be relative from the current directory, it's not very convenient to move files around or make a contained module that depend on its own module.

What? Not in my experience. For instance, I have lpeg install ~/.luarocks/lib/lua/5.4 and LuaXML in /usr/local/share/lua/5.4 (just to name two modules I use). To use them, it's just

    local lpeg = require "lpeg"
    local xml  = require "LuaXml"

I'm confused as to what you mean.

[giraffe_lady]

Yeah so this is both the "in charge of your own environment" and using luarocks, which is ignored by a big portion of the lua community.

A common situation is wanting to distribute a script that can be loaded and run by a lua-using environment, say a game client or something along those lines. What can you depend on? Can you expect or demand that users of your script have luarocks installed? If not then what is the path? On windows too? Do you maybe need to vendor that? Can you even? If the module is pure lua then fine, but lpeg isn't. Is the OS going to allow the host program to dlopen an unsigned C bin?

Lua is used for so many different things you could possibly never run into any of this stuff. But in my experience it's a major headache for a lot of uses. Partly this is a consequence of lua succeeding on its own terms, and being embedded in a lot of highly variable situations. But it still sucks in practice.