On Tue, Jun 14, 2011 at 9:42 AM, Reuben Thomas <[email protected]> wrote:
> I recently installed luarocks in my home directory on an Ubuntu
> machine. I share this home directory across x86 and x86_64 machines. I
> found it quite tricky to get luarocks to work like this, and it took
> me quite a while reading the documentation and code to get things to
> work cleanly. I finally came up with the following recipe, which I
> hope can be added to the documentation.
>
> 1. Install luarocks in home directory with: ./configure --prefix=$HOME/local
>
> 2. Set the following variables in .bashrc or similar:
>
> LUA_LIBDIR=$HOME/local/`uname -m`/lib/lua/5.1
> LUA_BINDIR=$HOME/local/`uname -m`/bin
> LUAROCKS_CONFIG=$HOME/local/etc/luarocks/config_`uname -m`.lua
> LUAROCKS_UNAME_M=`uname -m` "$@"
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?
> 3. 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 found all of these steps necessary. Some things it would be nice to fix:
>
> 1. Step 3 above (the per-arch config.lua) should be unnecessary: it
> should be possible to set LUAROCKS_ROCKS_TREE in the environment. (In
> general it is not clear from the docs which variables are read from
> the environment and which are not; they should all be.)
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).
> 2. It is not obvious from the documentation that LUAROCKS_CONFIG
> cannot be set on the command line (this is too late); it MUST be set
> in the environment. Is this a bug?
LuaRocks is at fault of causing a frequent confusion to users between
its internal variables and system environment variables. And then
there is config variables such as LUAROCKS_ROCKS_TREE and
rockspec-visible variables such as LUA_LIBDIR.
The 'make' command allows environment variables to be used as make
variables, with precedence rules. We could take a hint from that and
implement this:
hisham@parser ~]make HELLO=oi
echo oi
oi
hisham@parser ~]HELLO=oi make
echo oi
oi
hisham@parser ~]HELLO=oi make HELLO=what
echo what
what
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).
> 3. See this code from cfg.lua:
>
> -- A proper installation of LuaRocks will hardcode the system
> -- and proc values with config.LUAROCKS_UNAME_S and config.LUAROCKS_UNAME_M,
> -- so that this detection does not run every time. When it is
> -- performed, we use the Unix way to identify the system,
> -- even on Windows (assuming UnxUtils or Cygwin).
> system = config.LUAROCKS_UNAME_S or io.popen("uname -s"):read("*l")
> proc = config.LUAROCKS_UNAME_M or io.popen("uname -m"):read("*l")
>
> This is misguided, as it forces the user to set LUAROCKS_UNAME_M in
> their .bashrc. Instead, LUAROCKS_UNAME_M should only be put in
> config.lua on systems that lack the uname command. (The other obvious
> solution would be to install luarocks under lib/ rather than share/ so
> that it can be installed for multiple architectures, but that is
> overkill just for a single per-arch value.)
This is from LR1 days when luarocks/cfg.lua was loaded everytime one
used the LuaRocks require(), so I didn't want to have two forks when
the module was loaded. Caching the uname values seemed to make sense.
In LR2, we still load luarocks/cfg.lua when we use the custom loader,
but it is optional now (it's useful only for loading specific
dependencies when multiple versions of modules are installed -- not
the common case).
I think nowadays we could just not set LUAROCKS_UNAME_S and
LUAROCKS_UNAME_M on Unix installs.
> If you agree with my suggested changes, I'd be happy to make patches
> for any or all of them.
My take on the three items:
* I think uname caching can go.
* 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? If you need to pass a custom config file on each
luarocks invocation , then I suppose "luarocks --config=file foo" and
"LUAROCKS_CONFIG=file luarocks foo" are somewhat equivalent and the
latter is simpler to automate; it may be more a problem of
documentation than anything else.
* I'd like to hear more opinions about support for setting everything
through environment variables.
--
-- Hisham
http://hisham.hm/
_______________________________________________
Luarocks-developers mailing list
[email protected]
http://lists.luaforge.net/cgi-bin/mailman/listinfo/luarocks-developers
