Re: [ANN] Lift 0.1 looking for early adopters

That was not at all what I meant to send, sorry for the noise. Here is the real response.

>> - relative imports for intra-package modules.

> I did not understand this one, could you elaborate?

So by "module" I mean a single lua file that exports some value. A package is a unit of published code. It can be a single module or a directory containing several modules (but with one public export interface).

By relative imports I mean that in a multi-file package, modules can reference each-other without know the global path. In the current lua system, I have to know under what name my package will be installed to be able to reference other files with the same package.

    foo/
      init.lua
      a.lua

In lua, `foo/init.lua` would need a "foo.a.lua" or "foo/a.lua" to reference `init.lua`. If the package was renamed then all internal links would need renaming too.

In luvit, `init.lua` could just require "./a.lua" and not worry about where it is. Thus intra-package links become portable and relative.

Also for larger packages or apps the nested scoped I mentioned become useful.

   foo/
     libs/
       a.lua
     main.lua
     stuff/
       bar.lua

In this tree, anything below `foo/` can access anything within the `foo/libs/*` namespace as if it was a global module. Meaning `main.lua` can just require "a" and `stuff/bar.lua` can likewise just require "a". The algorithm looks for `./libs/%.lua` then `../libs/%.lua`, then `../../libs/%.lua`, etc. Thus giving arbitrarily scoped dependencies.

This is the design taken from node, but instead of calling it "node_modules", there are two paths (both "deps" and "libs") except "deps" is used by lit to install automatic dependencies and "libs" is used for internal dependencies not installed by lit. Having two different trees makes it easy to .gitignore one while committing the other.

This system combined with intra-package relative resolution makes for a really nice system.

Also the relative loading also works for arbitrary data files using the `module.*` API in luvit 2.x and the upcoming "resource" module in newre luvit. For example, my tls module contains a list of root certificates in a binary file. It just does a relative load to read them without having to know where it was installed (or even if it's on the filesystem at all, luvi can work out of zip files embedded in executibles).

Not all of this applies to the package manager, but it's nice that lit is smart enough to look for dependencies in deps and not install things already installed locally. Also it installs dependencies locally be default