Re: More about packaging (hopefully not too long)

[Mike Pall <mikelu-0406@...>]

Hi,

RLake wrote:
> function import(name)  _G[name] = require(name) end

Yes, that solves the 'lazy coder' problem with your scheme. However for
backward compatibility we need to reverse the names: import must be the
'clean' importer and require must be the 'lazy' importer (it needs to
return _G[name], too).

RLake wrote:
>   local mime = require "com.nehab.diego.mime"

I like that. Probably because I'm in the 'clean-namespace' camp. And
it's a lot faster, too (GETUPVAL+GETTABLE vs. GETGLOBAL+4*GETTABLE).
So I would always use the local foo = require "foo" variant anyway.
And I would use whatever logic I need to keep the global table for
a module clean. If that comes for free when I use the proper import
function, I'm all for it.

And I really don't see a problem in bracketing my library code with
whatever glue the proposed scheme requires.

In my cross-universe data exchange experiments I needed a (clean) way
to initialize each universe with all required libraries. That is not
so much different from your sandbox requirements. We both need to import
libraries multiple times. Exporting constructors and passing a table
to them solves that nicely.

All in all I'm +1 on this because we can satisfy both camps (clean vs. lazy)
and I see no real disadvantages. So forget about my proposal that does
it the other way round. Your solution is much cleaner.

The hierarchical import stuff could be solved by a site-customizable
name translator mapping "com.nehab.diego.mime" to "com/nehab/diego/mime"
or to "com.nehab.diego\\mime" or whatever. The default translator would be
the identity function.

> So it is logical (to me) to require the .dll and have it include mime.lua
> as a string constant. [...]
> (Nothing that a makefile couldn't fix, though.)

Nothing that a standard _installer_ couldn't fix. It needs to be
site-customizable and written in Lua of course. And you could customize it,
so the stub gets merged. The default would be to install two separate files.

Something like: lua setup.lua install

------ setup.lua ------
local setuputil = require "setuputil"

local spec = {
  name = "foo",
  description = "FooMatic System",
  version = "1.0.0",
  ...
  lua_lib = { "foo" },
  c_lib = {
    ["foo"] = {"foo.c", "bar.c", "foobar.h"},
  },
}

setuputil.run(spec, arg)
-----------------------

------ foo.lua --------
return requirelib("foo")        -- or importlib("foo")
-----------------------

The stub may be autogenerated if the lua_lib spec member is omitted.

No, I haven't written such a standard installer (yet). And please let's
keep the discussion focused on the key issues first. But I want to point
out that we can solve many side-issues by allowing the site-owner to
customize the install process (provided every library writer sticks
to using a standard installer).

Bye,
     Mike