Re: Proposal: smartlua

[John Labenski <jlabenski@...>]

On Tue, Mar 12, 2013 at 2:22 AM, steve donovan
<steve.j.donovan@gmail.com> wrote:
>>         > require "moon"
>>         Finding out available versions of moonscript...
>>         Getting moonscript-0.2.2 (binary)...
>>         Finding out available versions of lpeg...
>>         Getting lpeg-0.10.2 (binary)...
>>         Finding out available versions of alt-getopt...
>>         Getting alt-getopt-0.7 (binary)...
>
> Extremely cool, Michal. As you mention, the key thing is a database
> mapping modules to packages. Always thought that it would e.g. be very
> cool to say 'luarocks install lfs' but it turns out that this
> information in general isn't possible to extract from the repo [1]  So
> even starting that database is a very useful thing for everyone, e.g.
> I don't doubt that a version of intellua could be written for
> LuaRocks.

The one thing I have not seen in this thread is some sort of API
version control, maybe I missed it though.

For example: app requires "foo" version 1.0 and "foo" requires "bar"
version 1.0.

A couple years pass and the author of "bar" rewrites his code and it's
better than ever, but the public API has changed and he now calls it
version 2.0. If "foo" 1.0 naively requires "bar" without any version
constraints it won't work if it ends up getting "bar" version 2.0 [1].
The exact same problem exists for your "app" and its dependencies on
both "foo" and "bar," though in this case you have a little better
control since you can rewrite your app.

I have always wondered how this works for Lua users in practice and
concluded that most people work in their own little ecosystem where
they control the versions of everything. However, any Lua package
system would conceivably install them system wide (optionally) and so
"foo-1.0" should really require "bar-1.0." This means that instead of
libraries named foo.so and bar.so they should be named foo-1.0.so and
bar-1.0.so etc.

I don't believe I've seen this, is there anything wrong with doing
this and why isn't it done now?

local bar = require("bar-1.0") -- load "bar-1.0.so/dll" into the "bar" table

But then what about bar-1.0.1 ? Symbolic links in Linux solve this
problem easily, MS Windows not so much...

Throw into the mix that there might be needs to have
bar-1.0-Lua-5.1.so and bar-1.0-Lua-5.2.so etc...

It is an engineering nightmare and was wondering if people worried
about these problems or if the consensus was that you will get what
you get from the Lua package manager and you simply must match your
app to the package versions, buyer beware as they say.

Regards,
    John

[1] There are many flavors of versioning semantics, for example X.Y.Z
is API compatible for any Z given the same X.Y. Though the logic
breaks down if a library is dramatically updated so that, even if it
stays API compatible, it is so much better that X or Y should be
bumped to let people know the significance of the change. I don't want
this comment to become a distraction from my main question though.