lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index] 

Am 08.04.2014 05:01 schröbte Tim Hill:


On Apr 7, 2014, at 6:50 PM, Sean Conner <sean@conman.org> wrote:


  Your mention of "the right compiler" triggered a thought:  is the fagility
of require() due to Windows and not inherently with Lua itself?  (Or maybe a
distinction between a consumer operating system like Windows/Mac OS-X and a
non-consumer operating system like Unix? [1]) [2]



Partly, yes I think it is. But it’s also one of the more intricate
designs in Lua, which makes creating predictable installs of
libraries hard to do unless you control the complete OS installation,
libraries, and scripts, even assuming you can compile things
cleanly.

I have a sneaking suspicion most of this discussion is really about
the fragility of “require()”. Assuming for a moment Lua had a
bullet-proof “require” model so that all anyone had to do was
“require mathx” (with no OS/web tinkering) and you would get all
those hyperbolics, I wonder how many people would still have an issue
with moving them out of the math library?


Assuming we are not talking about syntax sugar, what could we do better?

Let's talk about pure Lua modules first, because that should be easier.
1. A user downloads and extracts a zip or tarball containing some directories and/or files. 2. The user navigates to the "module root directory" in the extracted directories, and copies all files and subdirectories somewhere into a directory that's in your `package.path`. On Windows that probably would be the directory where Lua is installed, but for non-admin users we could add another entry to `package.path` that points somewhere into the users home directory. Do we need support for a HOME or USER variable in the `package.path` templates? I think even Unix users would benefit from a `~/.lua/?.lua` entry in the default `package.path`. We probably also need some way to tell the user what/where the "module root directory" is. 
3.  `require` should just work, then.

Now for C modules:
1. The user could avoid many problems by downloading a ready-made binary. For Windows the LuaDist project provides such downloads. The downside is that have to take care to compile your own C modules or your own Lua binary in a compatible way. You need (at least) the same C runtime and the same Lua dll. For Linux etc. there are no binary downloads at the moment (other than in your favorite package repository), and I'm not sure how compatible a Linux binary (e.g.) will be across distros ... 2. You put the binding dll somewhere into `package.cpath` (again on Windows probably the Lua directory). We would probably benefit from a user-local default location here as well. 3. You put the library dll somewhere into your PATH (on Windows) or LD_LIBRARY_PATH (on Unixes). On Windows that could also be the Lua directory if the user put it into the PATH (or maybe the Windows directory?). On Linux your package manager takes care of this for you, or you install the library somewhere into `/usr/local`. 
4.  `require` should just work, then.
If we consider building C modules things get complicated very quickly unless we dictate compiler, flags, build tool, etc.
User-local entries in the default `package.path`/`package.cpath` seem to be useful. (Although one should assume that a programmer is able to set an environment variable once.)
What else can we do to make using external modules less fragile (I'm not sure how much `require` can contribute to that)?
Maybe we should concentrate on making LuaDist/LuaRocks easier to install instead (graphical installer, include mingw compiler in the package, etc.)?! 



—Tim



Philipp