Hi,

The current behavior is definitely incorrect. It is the result of the
interaction of various features, while trying to be over-careful to
"make sure all modules are found".

My hunch is that the generation of the wrapper script should honor the
settings of deps_mode (see this commit I just made for more
information:

https://github.com/keplerproject/luarocks/commit/2511c8377f6c924625b10d6e6cc77c5053890b94

I'll have to run some tests and give it some thought to make sure I
don't break anything else when fixing this, but it will be fixed in
the next release.

In the meantime, a workaround is to set your $APPROCKS tree as your
sole tree in your configuration file.

$ echo "rocks_trees = { [[$APPROCKS]] }" > my_config.lua
$ LUAROCKS_CONFIG=myconfig.lua luarocks install ldoc

Sorry about the mess.

-- Hisham

On 7 January 2014 01:55, Gary V. Vaughan <[email protected]> wrote:
> Hi Hisham,
>
> On Jan 7, 2014, at 4:49 PM, Gary V. Vaughan <[email protected]> wrote:
>> I'm trying to build a separate luarocks tree for a bundled package that
>> has access to all the rocks it needs, regardless of changes in the
>> main luarocks tree.
>>
>> This seems like the right way to do it:
>>
>>  $ APPROCKS=$APPHOME/rocks
>>  $ luarocks --tree=$APPROCKS ldoc
>>
>> But the resulting $APPROCKS/bin/ldoc binary has a crippled package.path:
>>
>>  $ cat $APPROCKS/bin/ldoc
>> #!/bin/sh
>>
>> exec '/usr/local/opt/lua/bin/lua' -e 'package.path="\
>> /usr/local/share/lua/5.1/?.lua;\
>> /usr/local/share/lua/5.1/?/init.lua;\
>> /Users/gary/.luarocks/share/lua/5.1/?.lua;\
>> /Users/gary/.luarocks/share/lua/5.1/?/init.lua;"\
>> ..package.path; package.cpath="\
>> /usr/local/lib/lua/5.1/?.so;\
>> /Users/gary/.luarocks/lib/lua/5.1/?.so;\
>> "..package.cpath'\
>> -lluarocks.loader \
>> -e 'luarocks.loader.add_context("ldoc","next-1")' \
>> '/Users/gary/rocks//lib/luarocks/rocks/ldoc/next-1/bin/ldoc' \
>> "$@"
>>
>> It seems counter-intuitive that not only is the main package path added
>> by default, but that even if I set LUA_PATH, the main package path takes
>> precedence.
>>
>> I must be missing something here, because I don't think I'm supposed to
>> manually edit all of the files in $APPROCKS/bin to hold proper package.paths.
>>
>> What is the proper way to set up a separate rocks tree to support an
>> application like this?  (Preferably without having to make a separate
>> custom luarocks install for each package).
>
> I should mention that if I run the equivalent of:
>
>   sed -ie "s|/usr/local/|$APPROCKS|" $APPROCKS/bin/*
>
> I can run $APPROCKS/bin/ldoc etc. correctly, as I was expecting to get
> by default.
>
> Cheers,
> --
> Gary V. Vaughan (gary AT vaughan DOT pe)

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Luarocks-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/luarocks-developers

Reply via email to