This needs to be in every Lua module in the application, Lua will upon reading such a require statement traverse the directory structure to find that module.
It doesn't matter if you move the (entire) directory structure to another location it will still work.
That is :
- if Lua can find your "main" module, but if it can't you don't have anything to run anyway :-)
- and if the base directory is in the Lua path.
Normally one would have a main module in the base directory which requires modules in sub directories and then life is good :-).
As far as I know changing package.path or other hacks are only sensible if you do things out of the ordinary (eg.: your installer copies all your 'personal library files' to a fixed location on the users computer which might not be in the Lua path, while your "main module" is on the Lua path (eg.: present directory) then you can add the location of your library files to package.path for example).
Wim
>> see below for further comments
On Wed, Feb 10, 2010 at 11:52 AM, spir
<denis.spir@free.fr> wrote:
On Mon, 8 Feb 2010 15:44:31 +0200
steve donovan <steve.j.donovan@gmail.com> wrote:
> On Sun, Feb 7, 2010 at 11:11 AM, spir <denis.spir@free.fr> wrote:
> > I guess the current dir (I mean ./) is not updated to /data when passing from the module "stack" to the module "STACK_CATS": when copying the file stack.lua into the top dir, all works fine. Am I doing something wrong? Is there a way to force module search in the actual current dir?
>
> The problem often appears when wanting a program to be self-contained.
Exactly. I guess this is what I'm trying to do. But indeed I cannot know (before runtime) what the top dir of the program is. Instead, I know the program's internal hierarchy.
use require statement relative to top directory (there shouldn't be a need to know the location of the top directory)
> Then the best way is for the main module to update package.path
> directly before requiring anything,
Thank you, Steve. I guess I will do that.
> but this requires that the module
> knows exactly where it is loaded from; you can usually get this from
> arg[0]. That is, say arg[0] is '/bonzo/dog/main.lua' then you can
> prepend '/bonzo/dog/?.lua;' to the package.path.
Yes. But for any reason arg[0] only tells me the module name without its path:
-- /home/spir/prog/lua/test/x.lua
print (arg[0]) --> x.lua
I can get the dir using
print(os.getenv("PWD")) --> /home/spir/prog/lua/test
on my computer, under linux, but this is indeed not portable.
Just to be sure I correctly understand. I naively thought the following: in the first path pattern of the require trial sequence "./?.lua", "./" refers to the path of the current module. Instead, if a requires b requires c, it seems "./" still refers to a's dir when b is run and requires c. As a consequence, "require 'c'" will search for c as "dir_of_a/c.lua" instead of "dir_of_b/c.lua". Correct? If I copy c into dir_of_a, all works fine.
use require "dir_of_b.c"
Then 2 more questions:
* What about sub directories in a given package/app: I guess they must also be added to package.path?
no
* During development, for debug/setup/testing, I often need to run modules independently (so, there is neither import nore direct run of the main module): how to ensure proper update of package.path?
Maybe test funcs/modules should all include an update of package.path?
if Lua can find the top directory it will also find your module
> steve d.
________________________________
la vita e estrany
http://spir.wikidot.com/
