lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


> wouldn't it make sense to include the `uv.lua` shim in the rock and use `require( "uv" )` everywhere?

Including the shim in the luarock isn't a bad idea.  I just don't know to do that.

> LuaRocks on LuaJIT will ignore the LuaBitOps rock anyway precisely because it is already provided built-in

That's good to know, but luv itself doesn't depend on the bit library.  Certain libraries written for luvit depend on it.  Their dependencies are declared within the lit ecosystem where it's assumed "bit" is provided by the runtime.


On Mon, Apr 25, 2016 at 11:42 AM, Philipp Janda <siffiejoe@gmx.net> wrote:
Am 25.04.2016 um 16:33 schröbte Ryan Pusztai:
On Sun, Apr 24, 2016 at 9:24 PM, Tim Caswell <tim@creationix.com> wrote:

Is the `lit install ... creationix/uv ...` redundant? I don't need that
if I LuaRocks installed "luv" correct? This was just for the example.

Actually, it's not redundant, as the article describes later on:

The deps/uv.lua shim is literally nothing more than `return require
'luv'` that redirects any requires to the luarocks version

In luvi based apps (luvit and lit), the luv module is required as "uv",
but in the luarocks land, it's "luv".  Most modules published to lit assume
the "uv" spelling.  So this shim makes them continue to work even though
we're using the luarocks version.


OK it was not clear to me from the article, but this explanation makes
perfect sense.

Actually not so much. Why??? Wouldn't that require different `luaopen_*` functions and different build rules?! If it's because of a name conflict with `uv.dll` on Windows, wouldn't it make sense to include the `uv.lua` shim in the rock and use `require( "uv" )` everywhere?


Also why did we need LuaBitOpts installed. It is not used in any of the
examples? If it is a dependency for luv why not include that in your
LuaRocks dependency list?

Again most luvit modules are written for luvit, which means luajit where
the bit library is a built-in.  But in this example we were using plain lua
so we needed to add the bitop library manually on the luarocks side so that
it would be compatible.  It's not listed as a dependency since it's part of
luajit normally.


Hum I wish this could be automatic in LuaRocks. Does it hurt LuaJit to have
LuaBitOpts installed? If not, I suggest adding it to the LuaRocks this way
it will work always. This is just my personal forgetful selfs opinion, but
the framework looks so good I want everyone to have success.

LuaRocks on LuaJIT will ignore the LuaBitOps rock anyway precisely because it is already provided built-in.

Philipp