Re: [ann] Blog post on Luvit without Luvit

Sounds good. So I need to add luabitop as a dependency. Even though it's not strictly needed for luv itself, it is needed by many libraries written for luv. I assume bitop is small enough someone using luv won't mind too much pulling in bitop in the case they didn't need it.

As far as "uv" vs "luv" I think the simplest solution is to just include uv.lua in the rock somehow.

I could instead rename the shared library itself to just "uv.so"/"uv.dll", but I worry about that breaking things (both for existing luv users and for systems where it conflicts with libuv itself.

On Tue, Apr 26, 2016 at 6:24 AM, Hisham <h@hisham.hm> wrote:

On 25 April 2016 at 11:33, Ryan Pusztai <rpusztai@gmail.com> wrote:
> On Sun, Apr 24, 2016 at 9:24 PM, Tim Caswell <tim@creationix.com> wrote:
>> > 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.

Since LuaRocks 2.1.2 (jan 2014), when LuaRocks is running under
LuaJIT, the "luabitop" dependency is assumed to be already installed.
So writing "luabitop" in the dependencies section of a rockspec means
that it will be installed when running in Lua, but it is a no-op in
LuaJIT.

Similarly, the "bit32" and "utf8" dependencies are assumed to be
installed if they are built in the interpreter, but can be fetched as
a rockspec in Lua installations when they are not. (There are
backports of the built-in Lua modules from Lua 5.2/5.3 in the LuaRocks
repository that load fine in Lua 5.1/LuaJIT).

-- Hisham