Location of a package

classic Classic list List threaded Threaded
128 messages Options
1234 ... 7
Reply | Threaded
Open this post in threaded view
|

Location of a package

Ignacio Burgueño
Hi everyone.
Is it possible for a module to know where it is placed when being required? I mean, if I have several places specified in my package.path, I'd like the module to be aware of where it was picked up from. That's because I want my module to be able to construct full pathnames pointing to files in subdirectories.

If the answer is 'no', or 'no unless you patch Lua', then do you have any suggestions on how to deal with "resource files"? If my module is at c:\foo\bar\myModule.lua, I need to load files from c:\foo\bar\resource.txt or c:\foo\bar\blah.jpg, and the only path I'd like to configure is the one I set in package.path, so I can't hard-code the paths in myModule.lua

Also, I can't rely on parsing the package.path, since I might remove the path I used to require my module.

Regards,
Ignacio Burgueño



Reply | Threaded
Open this post in threaded view
|

Re: Location of a package

Petite Abeille-2-2

On Feb 18, 2008, at 9:21 PM, Ignacio Burgueño wrote:

Is it possible for a module to know where it is placed when being required

Hmmm... well... kind of... you can try debug.getinfo( aFunction, 'S' )... 'aFunction' being a, hmmm, function in the package you are trying to locate...

Reply | Threaded
Open this post in threaded view
|

Re: Location of a package

Tomás Guisasola-2
In reply to this post by Ignacio Burgueño
	Hi Ignacio

> I'd like the module to be aware of where it was picked up from. That's 
> because I want my module to be able to construct full pathnames pointing 
> to files in subdirectories.
	Why don't you use relative pathnames?

> If the answer is 'no', or 'no unless you patch Lua', then do you have 
> any suggestions on how to deal with "resource files"?
> If my module is at c:\foo\bar\myModule.lua, I need to load files from 
> c:\foo\bar\resource.txt or c:\foo\bar\blah.jpg, and the only path I'd 
> like to configure is the one I set in package.path, so I can't hard-code 
> the paths in myModule.lua
	Why don't you put everything in a proper directory?:

c:\foo\bar\myModule\init.lua
                   \resource.txt
                   \blah.jpg

	Regards,
		Tomás


Reply | Threaded
Open this post in threaded view
|

Re: Location of a package

Ignacio Burgueño
In reply to this post by Petite Abeille-2-2
Petite Abeille wrote:

On Feb 18, 2008, at 9:21 PM, Ignacio Burgueño wrote:

Hmmm... well... kind of... you can try debug.getinfo( aFunction, 'S' )... 'aFunction' being a, hmmm, function in the package you are trying to locate...



Thanks, I'll save that as a last resource, since it's possible that I don't have access to the debug library.




Reply | Threaded
Open this post in threaded view
|

Re: Location of a package

Petite Abeille-2-2

On Feb 18, 2008, at 9:39 PM, Ignacio Burgueño wrote:

Thanks, I'll save that as a last resource, since it's possible that I don't have access to the debug library.

Hmmm... well... then... you can always wrap require() with your own function and perhaps set the module path there...



Reply | Threaded
Open this post in threaded view
|

Re: Location of a package

Fabio Mascarenhas
Yeah, this is what the WSAPI launchers do with Orbit apps (along with
isolating each application in its own Lua state, but reusing the state
between different requests).

--
Fabio Mascarenhas

On Feb 18, 2008 5:07 PM, Petite Abeille <[hidden email]> wrote:
>
> On Feb 18, 2008, at 9:39 PM, Ignacio Burgueño wrote:
>
> > Thanks, I'll save that as a last resource, since it's possible that
> > I don't have access to the debug library.
>
> Hmmm... well... then... you can always wrap require() with your own
> function and perhaps set the module path there...
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Location of a package

Ignacio Burgueño
In reply to this post by Tomás Guisasola-2
Tomas Guisasola Gorham wrote:
	Hi Ignacio

I'd like the module to be aware of where it was picked up from. That's because I want my module to be able to construct full pathnames pointing to files in subdirectories.
	Why don't you use relative pathnames?

I can't. That's exactly what I'm trying to avoid. Maybe some info about what I'm trying to do is needed.

I'm doing some web stuff based upon Xavante, CgiLua and Orbit. From Xavante, I stripped the Copas' based server and replaced it with a multithreaded one written in C. I have a pool of luaStates, so when serving a request, I pick a state and pass control to it. From that point on, it behaves like Xavante, parsing the request, picking the right handler, etc.

I need to move away from relative paths because I can have two scripts running at the same time, each of them in different physical directories. I had to tweak CGILua to avoid changing directories and running each script with a full path.

This is working fine, I just prepend cgilua.script_pdir to the file I want to run. My problem is with Orbit. It relies on the process' current directory being the one in which the "orbit-enabled" app is located.

I'd like to avoid PA's suggestion about using debug.getinfo, since I might need to remove it, to disallow scripts fiddling with it. And I also would like to decrease the amount of 'path configuration' needed. I just want to say where a module is to be required, then I want the module itself to figure where are its resources.

Regards,
Ignacio Burgueño




Reply | Threaded
Open this post in threaded view
|

Re: Location of a package

Fabien-3
It's unfortunate that the package finder function isn't exposed in Lua by the native package lib. I hope it will be done
in Lua 5.2.

Metalua needs it, and reimplements it. Look at function package.findfile() in
http://repo.or.cz/w/metalua.git?a=blob_plain;f=src/lib/package2.lua, and give it your package's name as first arg,
package.cpath or package.path as a second arg, depending on whether your module is in C or in Lua. Don't
forget to close the file handle if you don't use it.

-- Fabien.
Reply | Threaded
Open this post in threaded view
|

Re: Location of a package

Roberto Ierusalimschy
> It's unfortunate that the package finder function isn't exposed in Lua by
> the native package lib. I hope it will be done
> in Lua 5.2.
> 
> Metalua needs it, and reimplements it. Look at function package.findfile()in
> http://repo.or.cz/w/metalua.git?a=blob_plain;f=src/lib/package2.lua, and
> give it your package's name as first arg,
> package.cpath or package.path as a second arg, depending on whether your
> module is in C or in Lua. Don't
> forget to close the file handle if you don't use it.

Lua 5.2 will include a package.searchpath function. It is similar
to this package.findfile, but it returns only the file name (not the
file handler).

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Location of a package

Yuri Takhteyev
Speaking of which:  is there a better way to check whether a package
is available other than using require() and catching errors with
pcall()?

  - yuri

On Mon, Feb 18, 2008 at 12:19 PM, Roberto Ierusalimschy
<[hidden email]> wrote:

>  Lua 5.2 will include a package.searchpath function. It is similar
>  to this package.findfile, but it returns only the file name (not the
>  file handler).
>
>  -- Roberto
>

Reply | Threaded
Open this post in threaded view
|

Re: Location of a package

eugeny gladkih
In reply to this post by Roberto Ierusalimschy
>>>>> "RI" == Roberto Ierusalimschy <[hidden email]> writes:

 >> It's unfortunate that the package finder function isn't exposed in Lua by
 >> the native package lib. I hope it will be done
 >> in Lua 5.2.
 >> 
 >> Metalua needs it, and reimplements it. Look at function package.findfile()in
 >> http://repo.or.cz/w/metalua.git?a=blob_plain;f=src/lib/package2.lua, and
 >> give it your package's name as first arg,
 >> package.cpath or package.path as a second arg, depending on whether your
 >> module is in C or in Lua. Don't
 >> forget to close the file handle if you don't use it.

 RI> Lua 5.2 will include a package.searchpath function. It is similar
 RI> to this package.findfile, but it returns only the file name (not the
 RI> file handler).

Roberto, is there any description of upcoming changes in Lua 5.2?

-- 
Yours sincerely, Eugeny.
Doctor Web, Ltd. http://www.drweb.com
+79119997425

Reply | Threaded
Open this post in threaded view
|

Re: Location of a package

Petite Abeille
In reply to this post by Yuri Takhteyev

On Feb 18, 2008, at 9:37 PM, Yuri Takhteyev wrote:

Speaking of which:  is there a better way to check whether a package
is available other than using require() and catching errors with
pcall()?

E.g.:

local ok, zlib = pcall( require, 'zlib' )

What's wrong with it?




Reply | Threaded
Open this post in threaded view
|

Re: Location of a package

Ignacio Burgueño
In reply to this post by Fabio Mascarenhas
Fabio Mascarenhas wrote:
Yeah, this is what the WSAPI launchers do with Orbit apps (along with
isolating each application in its own Lua state, but reusing the state
between different requests).



Could you point me to some sample code? I'm looking at both wsapi and orbit's source and I can't find where you do that.

I mean, if I have two apps which serve static content, both placed in different directories, how does Orbit handle that? orbit.serve_static will fail unless given a full pathname.

Regards,
Ignacio Burgueño



Reply | Threaded
Open this post in threaded view
|

Re: Location of a package

Fabio Mascarenhas
Start from src/launcher/wsapi.fcgi in the WSAPI CVS and follow the
function calls to src/wsapi/common.lua.

And orbit.serve_static has to work with relative paths (looking in the
cwd, of course), what problems are you having?

--
Fabio Mascarenhas

On Feb 18, 2008 6:34 PM, Ignacio Burgueño <[hidden email]> wrote:
> Fabio Mascarenhas wrote:
> Could you point me to some sample code? I'm looking at both wsapi and
> orbit's source and I can't find where you do that.
>
> I mean, if I have two apps which serve static content, both placed in
> different directories, how does Orbit handle that? orbit.serve_static
> will fail unless given a full pathname.
>
> Regards,
> Ignacio Burgueño
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Location of a package

Ignacio Burgueño
Fabio Mascarenhas wrote:
Start from src/launcher/wsapi.fcgi in the WSAPI CVS and follow the
function calls to src/wsapi/common.lua.

And orbit.serve_static has to work with relative paths (looking in the
cwd, of course), what problems are you having?


I've described my problem in a response to Tomás Guisasola. I'll copy+paste it here in case the message didn't get through.

Tomas Guisasola Gorham wrote:
>     Hi Ignacio
>
>> I'd like the module to be aware of where it was picked up from. That's because I want my module to be able to construct full pathnames pointing to files in subdirectories.
>     Why don't you use relative pathnames?

I can't. That's exactly what I'm trying to avoid. Maybe some info about what I'm trying to do is needed.

I'm doing some web stuff based upon Xavante, CgiLua and Orbit. From Xavante, I stripped the Copas' based server and replaced it with a multithreaded one written in C. I have a pool of luaStates, so when serving a request, I pick a state and pass control to it. From that point on, it behaves like Xavante, parsing the request, picking the right handler, etc.

I need to move away from relative paths because I can have two scripts running at the same time, each of them in different physical directories. I had to tweak CGILua to avoid changing directories and running each script with a full path.

This is working fine, I just prepend cgilua.script_pdir to the file I want to run. My problem is with Orbit. It relies on the process' current directory being the one in which the "orbit-enabled" app is located.

I'd like to avoid PA's suggestion about using debug.getinfo, since I might need to remove it, to disallow scripts fiddling with it. And I also would like to decrease the amount of 'path configuration' needed. I just want to say where a module is to be required, then I want the module itself to figure where are its resources.

Regards,
Ignacio Burgueño



Reply | Threaded
Open this post in threaded view
|

Re: Location of a package

Ignacio Burgueño
In reply to this post by Roberto Ierusalimschy
Roberto Ierusalimschy wrote:

...


Lua 5.2 will include a package.searchpath function. It is similar
to this package.findfile, but it returns only the file name (not the
file handler).



I recall a discussion about splitting the 'require' logic in two parts. I don't remember if it was on the Kepler dev's list or here. Anyway, it was about decoupling the process of finding a module from the actual loading of the module. Surely someone who took part in that discussion will be reading this.

Will issues like this be addressed in Lua 5.2 ?

Regards,
Ignacio Burgueño



Reply | Threaded
Open this post in threaded view
|

Re: Location of a package

Ignacio Burgueño
In reply to this post by Fabien-3
Fabien wrote:
It's unfortunate that the package finder function isn't exposed in Lua by the native package lib. I hope it will be done
in Lua 5.2.

Metalua needs it, and reimplements it. Look at function package.findfile() in http://repo.or.cz/w/metalua.git?a=blob_plain;f=src/lib/package2.lua, and

Thanks Fabien, I'll take a look at it.




Reply | Threaded
Open this post in threaded view
|

upcoming changes in Lua 5.2 [was Re: Location of a package]

Roberto Ierusalimschy
In reply to this post by eugeny gladkih
> Roberto, is there any description of upcoming changes in Lua 5.2?

There is no "official" roadmap :) The following is a list of what we
have been doing.

We have already implemented several small changes:

- emergency garbage collector (core forces a GC when allocation fails)

- ephemeron tables (tables with weak keys only visit value when
key is accessible)

- handling of non-string error messages (somewhat along the lines of
John Belmonte's suggestion)

- new function package.searchpath

- "metamethods" __pairs & __ipairs

- tables and strings respect __len metamethod

- udata with finalizers are kept in a separated list for the GC

- arguments for function called through xpcall


We are also considering the following changes:

- string.pack/string.unpack (along the lines of struct/lpack)

- Mike Pall's implementation for yield (using longjmp), allowing yields
in several places not allowed currently (inside pcall, metamethods, etc.)

- some form of bit operations. (We are not very happy with any
known implementation. Maybe just incorporate bitlib?)

- there is already a new function luaL_tolstring (along the lines of
the 'tostring' function). Maybe we should define a lua_rawtostring (no
coercions from numbers) and then use luaL_tolstring ("full" coercion
from other types) when we want to allow coercions. The point is where
to use one and where to use the other. (The current lua_tostring behavior
would be deprecated in the future...)


-- Roberto


Reply | Threaded
Open this post in threaded view
|

Re: Location of a package

Roberto Ierusalimschy
In reply to this post by Ignacio Burgueño
>> Lua 5.2 will include a package.searchpath function. It is similar
>> to this package.findfile, but it returns only the file name (not the
>> file handler).
>
>
> I recall a discussion about splitting the 'require' logic in two parts. I 
> don't remember if it was on the Kepler dev's list or here. Anyway, it was 
> about decoupling the process of finding a module from the actual loading of 
> the module. Surely someone who took part in that discussion will be reading 
> this.
>
> Will issues like this be addressed in Lua 5.2 ?

'require' already decouples its process of finding a module, using
loaders. This new function package.searchpath will easy the task of
writing new loaders. (E.g., both the C loader and the Lua loader are
just calls to searchpath.)

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: upcoming changes in Lua 5.2 [was Re: Location of a package]

Hans Hagen
In reply to this post by Roberto Ierusalimschy
Roberto Ierusalimschy wrote:
Roberto, is there any description of upcoming changes in Lua 5.2?

There is no "official" roadmap :) The following is a list of what we
have been doing.

will lpeg end up in the core?

Hans


-----------------------------------------------------------------
                                          Hans Hagen | PRAGMA ADE
              Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
     tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com
                                             | www.pragma-pod.nl
-----------------------------------------------------------------

1234 ... 7