Re: Proposal: smartlua

[William Ahern <william@...>]

On Thu, Mar 14, 2013 at 04:08:45AM -0400, John Labenski wrote:
<snip>
> 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.

Consider that after 30 years Microsoft still can't get this right. And while
Unix does a better job, very few people understand the details, and in any
event it's actually rare for different minor version of libraries to
coexist.

Perl doesn't really do versioning, nor do most other scripting environments.
There's varying support but it's rare to bother because there's very little
return on investment. Heck, even Java doesn't do this well.

Best practice is to focus on a good API at the outset and strive for
backward compatibility, IMHO. And demand the same from others.

> 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...

I don't know about Windows, but on Unix Lua modules go into Lua version
specific directories, at least with stock Lua and LuaJIT. Where package
maintainers go wrong is the naming of the compiled library and placement of
headers, but that's a different issue.

> 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.

By sheer number most Lua modules are fire-and-forget. People throw stuff up
and walk away. For other stuff... I guess it's a nightmare only if you can't
trust the maintainer to put some effort into backward compatibility.