[Luarocks-developers] LuaRocks and command-line scripts

[Peter Drahoš]

On 27 Jul 2007, at 23:09 , Hisham Muhammad wrote:
> On 7/27/07, Peter Drahoš <geranium42 at gmail.com> wrote:
>> The %~p0 trick should work on Win95 and works on 2000 and NT. It has
>> proven to be the easiest way to set the variables without any
>> installer and works on all the machines we test on. This approach is
>> limited for other installs than LuaDist as normally I have no idea
>> where lua is installed. LuaDist generates the paths in the wrapper
>> during installation so I know where lua and luarocks config is
>> relatively to the wrapper. Using the %~p0 trick inside the batch
>> wrappers alone does not help as the only thing I gain from this is
>> the path that the wrapper is in but I have no way to guess where lua
>> or luarocks config is. Environment variables must be used instead, to
>> be specific you need to have lua in your PATH.
>
> For other installs, assuming lua is in the PATH is not too bad, I  
> think.

I did a clean-machine step by step install with lua binaries on  
windows and additionally to the correct PATH you will need to set up  
LUA_PATH correctly so you can require luarocks. That makes two  
variables and if you use different luarocks config placement than the  
default one you will have to keep LUAROCKS_CONFIG correct too.

Getting CMake rocks to build requires no global variables to be set  
in most cases.  Make based rocks are a different chapter and I cannot  
tell what paths and variables will need to be set for those to work  
correctly, I still don't have a clue on how to get those to work.

This probably deserves a wiki entry "step-by-step luarocks  
installation on windows". Still, LuaDist works without any variables  
set up so LuaRocks on windows should be fine even if some newcomers  
come by and ask for a simple solution.

>>> ...
>> As mentioned I already have a solution that uses batch wrappers with
>> both absolute and relative paths I still need to test it before I
>> commit it. To partially solve this issue I would suggest we simply
>> add a new command to luarocks which would be the platform independent
>> way to run the scripts. eg. calling "luarocks run luacov" would call
>> bin/luacov in the luacov rock. While its not a solution it could be
>> sort of a fallback if all else fails.
>>
>> I can solve this issue differently in LuaDist with the %~p0 trick
>> used to find lua but it would be nice to do it in a way that does not
>> modify LuaRocks code.
>
> I had already thought about storing command-line script information in
> the manifest for something like 'luarocks run'. This keeps the door
> open for command-line script versioning too. I committed the addition
> of this data to the manifest; will add 'luarocks run' later.
>
> My inclination now is to generate simple sh/.bat wrappers based on a
> base environment variable which will be good for most cases and
> provide 'luarocks run' as a fallback (which could be used by the
> LuaDist general wrapper if you consider necessary.) How does it sound?

Sounds great! I could definitely use that in the windows wrapper.

After reading Andre's mention of the BASE approach and this feature I  
now have a different approach I can use in the wrappers which could  
move anywhere you want while your LUAROCKS_CONFIG is correctly setup.  
You can always get to the BASE (meaning installed rocks) when you  
have the correct config.lua. No absolute or relative paths are in  
fact needed.

There are currently three sources that I can use in the wrapper to  
get to the luarocks config.lua.
1. LUAROCKS_CONFIG environment variable which has the highest priority.
2. LUAROCKS_CONFIG variable stored in the wrapper (as is currently  
used in fs_unix.lua) which would be only used if the file still exists
3. System default one which is used when 1 and 2 fail.

Once luarocks has the correct config I could just rely on  
"luarocks.run" which should have every path it needs to call the  
script. This way we could move the repository or wrappers as needed  
and would eliminate most issues that I can think of.

pd