Re: Packaging and importing

[Chris Marrin <chris@...>]

Diego Nehab wrote:
> Hi,
>
> The package proposal allows for a lot of freedom. This is because Lua is
> used embeded in applications that might have especial needs.
>
> But does suggests the standard way of writing a package. This is with
> the use of the module() function.  This function has a very well
> specified behaviour. If your package uses module() (and it should use
> it), then both
>
>     local foo = require"foo"
>     a = foo.bar(5)
>
> and
>
>     require"foo"
>     a = foo.bar(5)
>
> will work. That's it. This is true of all libraries that don't try to be
> creative by not using module().

That sounds good. I think library writers (as all programmers, and oh 
what the hell everyone) are basically lazy. If there is an easy way to 
do something they will use it. That's great because it means consistency 
will be the easy thing to do. Of couse, some library writers will have 
to be shamed into updating their libraries to use module :-)

Looking at the implementation of module it looks like it actually does 
place the module name in the global namespace. But that seems 
problematic for the reason mentioned here before. If I <<require "a">> 
then <<require "b">>, if "a" requires "c" and then "b" requires 
something different called "c" (because it fiddled with the path and 
looked someplace different), now "a" is using the wrong "c", right? Or 
am I missing something about how setfenv() works? I admit that I am 
having trouble understanding how setfenv() helps setting up an 
environment for an entire module when you just set it on a single function.

> The proposal also specifies search order and search locations for all
> types of libraries. It also specifies how to override many details that
> can be specific to your deployment platform, doing so in such a way that
> will make other people's libraries work in your system anyways.
>
> At the moment, we are in transition. In the future, all libraries should
> be be consistent. Please consider using the package proposal, as it will
> make everyone's life easier in the long run.

Yes, it is a very good step toward consistency!

> If there is anything you would like to be able to do when you package
> your libraries, but feel you can't do with our proposal, this is the
> right venue to talk about it. Chances are we can figure out how to do it
> so that everything is compatible.

Thanks for the help so far. My big issues still have to do with 
isolating namespaces. For instance, what about the problem I mention 
above? Are modules required by "b" isolated from those required in "a", 
like they are in Python? Also, has anyone made a proposal for how you 
can promote all the members of "a" into the namespace of the module that 
requires "a"?

Thanks again...

--
chris marrin              ,""$, "As a general rule,don't solve puzzles
chris@marrin.com        b`    $  that open portals to Hell" ,,.
        ,.`           ,b`    ,`                            , 1$'
     ,|`             mP    ,`                              :$$'     ,mm
   ,b"              b"   ,`            ,mm      m$$    ,m         ,`P$$
  m$`             ,b`  .` ,mm        ,'|$P   ,|"1$`  ,b$P       ,`  :$1
 b$`             ,$: :,`` |$$      ,`   $$` ,|` ,$$,,`"$$     .`    :$|
b$|            _m$`,:`    :$1   ,`     ,$Pm|`    `    :$$,..;"'     |$:
P$b,      _;b$$b$1"       |$$ ,`      ,$$"             ``'          $$
 ```"```'"    `"`         `""`        ""`                          ,P`