lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

It was thus said that the Great Timm S. Mueller once stated:
> One such pluggable handler would allow to require() or dofile() from a
> ZIP archive or from memory, for example. These are traits that I
> suspect would need to go to the core.

  Lua already has most of the functionality for that built in, and I was
able to load Lua modules (written in Lua) directly from a ZIP file [1][2]. 
Look up package.searchers[] (package.loaders[] for Lua 5.1).  

> The concrete implementation of that interface that would be shipped
> with Lua is not so important to me. By default it should be really just
> a thin, naive wrapper on ANSI and POSIX. Directory functions could even
> return an error if the functionality is by default not supported. But
> you could require for example a "fs.default" handler to implement the
> filesystems of most common operating systems.

  ANSI does not provide any file system API other than opening and closing
of files.  POSIX does, but there are other non-POSIX systems out there.



	It's intent was to distribute and run Lua applications directly from
	a ZIP file.  It ... somewhat works [2].

[2]	C based Lua modules could not be loaded direction from the ZIP file
	(a limitation imposed by the operating system).  So those had to be
	written out to disk before loading.  Also, any files that Lua opens
	for modification also had to be written out to disk.  Other than
	that, yes, I could run an application directly from a ZIP file [3].

[3]	I was able to package up and run LuaRocks this way.