Re: Path change to LUA_CPATH in Lua Binaries

[David Manura <dm.lua@...>]

Antonio Scuri writes:
> ...today Lua for Windows must add two entries to the PATH and set
> LUA_CPATH/LUA_PATH environment variables. This turns hard to have
> two different Lua versions installed on the system...

RJP Computing writes:
> Lua for Windows will not be setting the LUA_PATH or LUA_CPATH
> any more. It will use the defaults. But, because of the way Windows
> loads dlls Lua for Windows will continue to add two PATH variables;
> one for the lua.exe directory and one for the 'clibs' directory so
> that modules will load correctly.If and when the official Lua changes
> to using LoadLibraryEx with the flag LOAD_WITH_ALTERED_SEARCH_PATH
> Lua for Windows will remove the 'clibs' directory from the PATH
> environment variable.Thoughs?

A fundamental problem as I see it is that one wants to configure startup
behavior (e.g. LUA_PATH/LUA_CPATH/LUA_INIT) of a private instance of Lua without
recompiling it, without wrapping it (e.g. a .bat/.sh file setting local
environment variables), and without setting global parameters (e.g. global
environment variables, system-wide config files, or registry settings). The
obvious solution to this is for Lua, upon startup, to look for this information
in some file parallel to it (e.g. c:/programs/mylua/lua.exe will look in
c:/programs/mylua/lua.exe.config).  In Windows, this path is obtained via
GetModuleFileName().  Alternately, it could look for this info in the resource
section of its EXE, which can be modified without recompiling the EXE.  Doesn't
this so resemble manifests?  That's not necessarily to say we can or want to
store this information in the manifest machinery (i.e. lua.exe.manifest), but
the approach is similar.  Most generally, lua.exe.config could be a Lua file,
which could execute arbitrary code (e.g. setting package.path and
package.cpath).  Like loadlib, this relies on the non-ANSI function
GetModuleFileName(), so this feature could be selectively enabled in luaconf.h.
 LuaBinaries could enable it.  Alternately, this behavior might be implemented
in luaL_openlibs in a lua51.dll that acts as a shim that proxies to the real but
renamed lua51.dll, along the lines of [1].  In fact, Lua Binaries already
provides a shim (lua51.dll/lua5.1.dll).

This proposal doesn't solve all problems though; I think you would still want
LOAD_WITH_ALTERED_SEARCH_PATH for LuaRocks.

[1] http://lua-users.org/wiki/LuaProxyDll