On 14 June 2011 21:21, Hisham <[email protected]> wrote:
>
> Are you sure all these variables can be loaded from the environment?
> Looking at the code it seems only LUAROCKS_CONFIG is settable like
> this. Or did you tweak the code?
I think I've made a mistake here, because in my first draft I set most
of these on the command line. That created an extra annoyance which
was that I had to rename luarocks to luarocks.real and write a wrapper
script luarocks to set the variables. I didn't test my simpler
"solution" properly, sorry.
This means that the procedure I sent should be:
1. Install luarocks in home directory with: ./configure --prefix=$HOME/local
2. Rename luarocks to luarocks.real and write a wrapper script
luarocks containing:
/bin/sh
luarocks.real LUA_LIBDIR=$HOME/local/`uname -m`/lib/lua/5.1
LUA_BINDIR=$HOME/local/`uname -m`/bin LUAROCKS_UNAME_M=`uname -m` "$@"
3. Set the following variable in .bashrc or similar:
LUAROCKS_CONFIG=$HOME/local/etc/luarocks/config_`uname -m`.lua
4. For each architecture, create a file to
$HOME/local/etc/luarocks/config_`uname -m`.lua of this form:
rocks_servers = {
[[http://luarocks.org/repositories/rocks]]
}
rocks_trees = {
home..[[/local/x86_64]] -- set arch as appropriate
}
> I think the original plan was to have only LUAROCKS_CONFIG to be set
> through the environment and then configure everything else through the
> config file. LUA_BINDIR and LUA_LIBDIR should be settable through the
> 'variables' table in the config file (ugly name, I know).
This multiplies the number of config files you need up to one for each
arch/Lua version combination. Unless of course there is some way to
substitute the arch into a config.lua file, but as far as I can tell
that's not possible as the arch is not yet known when the config file
is read. With my scheme the config.lua files work with any Lua version
and you just need one extra wrapper script per version of Lua.
> Would something like this be desirable? I did think about it back in
> the day. At first I decided against this: since rockspec authors can
> create variables through external dependency declarations, I was
> fearful of causing unexpected behavior due to existing unrelated
> variables in users' environments (Unix environment variables are one
> big global namespace, after all).
I think careful naming is the answer here. Environment variables are
best used for telling programs about properties of the environment.
For LuaRocks, the main piece of information to be communicated is the
location of Lua. The nice thing about using environment variables to
do this is that the architecture can be substituted in without any
support in LuaRocks.
> My take on the three items:
>
> * I think uname caching can go.
Fine, that's easy.
> * Accepting LUAROCKS_CONFIG through the command line (or a flag) may
> be tricky to implement cleanly due to the current design. And is this
> really necessary?
I think I agree that it is not.
In conclusion, I don't mind having to install LuaRocks separately for
each Lua version. (In the long run, an old version of Lua will
probably need an old version of LuaRocks.) I don't expect to have to
install LuaRocks separately for multiple architectures, because
LuaRocks itself is architecture-neutral. Finally, if I want to use
non-default rocks sets, I don't mind having manually to provide a --to
argument or other similar manual indication.
In summary, the recipe I gave above should reduce to setting a single
environment variable, and writing a single config.lua which itself can
refer to the architecture as a variable. This is achievable by the
single step you agree with above, namely not caching the architecture.
If therefore you would like me to write a patch to remove architecture
caching, I would be happy to do that.
--
http://rrt.sc3d.org
_______________________________________________
Luarocks-developers mailing list
[email protected]
http://lists.luaforge.net/cgi-bin/mailman/listinfo/luarocks-developers
