Luarocks + Corona SDK

I am trying to use luarocks to modularize my code. I created the following rock:

http://luarocks.org/modules/tyrondis/coronalog (https://github.com/tyrondis/coronalog)

In my Corona project I am installing it into a local tree:

$ luarocks install --tree lua_modules coronalog

This installs the rock into the following path:

./lua_modules/share/lua/5.1/coronalog.lua

Now I am changing lua’s search path so that I can easily include the module:

package.path = ‘lua_modules/share/lua/5.1/?.lua’ … package.path

However, after requiring the module:

local log = require(‘coronalog’)

Corona Simulator gives me the following error:

ERROR: Runtime error

module ‘coronalog’ not found:

   no field package.preload[‘coronalog’]

   no file ‘lua_modules/share/lua/5.1/coronalog.lua’

   …

The search path lua_modules/share/lua/5.1/coronalog.lua is correct and the file definitely exists there, however, Corona Simulator is unable to load it.

Am I doing this wrong or does Corona have no support for adjusting the search path? I would really like to be able to use luarocks. Package managers are a must for modern app development.

I may not have all the technical details straight, but I don’t believe you’ll ever be able to do this. Corona uses it’s own localized instance of Lua (this is the part where I’m making assumptions, so feel free to correct me @CoronaLabs). You can run the simulator and create builds without installing lua on your development machine, so installing modules via luarocks is not possible.

That said, luarocks support would be a feature request I’d get behind big time. But it may not be feasible as it could make the product impossible to support for the engineers in the way Corona users are accustomed to.

Jason is right. Corona SDK has Lua built in. We do not use the installed version of Lua. To work on a device we have to include Lua as part of the app. We have to use a predictable version. We are not going to traverse any installed version of Lua’s paths.

Code generated out of LuaRocks might be usable if you include it in your Corona Project Path and the code is compatible with the version of Lua we are using (5.1 I think).

Rob

Maybe you misunderstood me. I am totally aware that Corona SDK has Lua built in. I am not referencing luarocks outside of my project’s source code. 

$ luarocks install --tree lua_modules coronalog

installs the rock’s content (which is lua source code) in a subdirectory lua_modules in my Corona project, not in some system directory. Still I need to tell lua to search modules in that subdirectory by setting package.path. Corona even is able to resolve the path correctly, as we can see in the stack trace, yet it does complain that the file does not exist.

@tyrondis: if coronalog.lua gets placed inside of a lua_modules subdirectory of your Corona project, then you should be able to require it in by calling

local coronalog = require("lua\_modules.coronalog")

But I think I understand - you want to simply be able to call

local coronalog = require("coronalog")

This may not be precisely what you’re looking for, but if you are on OS X, then you can place modules in the Simulator’s “plugins” folder found here:

~/Library/Application Support/Corona/Simulator/Plugins

and be able to require them in as if they were native libraries. For example, I placed a test.lua file in there, required it by calling

local test = require("test")

and it worked as expected. Perhaps that’s where you should install your luarocks files. Keep in mind that this is outside the recommended user behavior, so tread carefully - infringing on SDK namespaces in that folder could throw things out of whack, and future SDK changes could also make this workaround unstable. I also haven’t tested building for device using files placed in that directory, so I can’t speak to any weirdness that may occur when you do.

But I’m still not sure I completely understand your request. To may way of thinking this seems like a lot of hoops to jump through just to get a Lua module in your project. But different strokes for different folks. :slight_smile: Hope I’ve managed to help a little bit at least. :slight_smile:

Jason have you tried that technique with device builds?

Rob

@Rob: I had not tried it before - I could only vouch that it worked in the simulator. I made an iOS device build and it definitely  does not work on device. My bad for suggesting a hacky workaround in the first place. ¯_(ツ)_/¯

It is certainly overkill for just one module. But this was just for me to try if it works. If you have multiple modules loaded from luarocks with interdependencies, they need to be able to resolve each other. And you cannot modify their source to look in a different path.

I believe also that LuaRocks not only has dependencies to deal with, but some rocks actually need to be compiled against other system components (which LuaRocks handles on install).

As you know, Lua has two major use cases; as a stand-alone interpreter, and/or a layer to expose a simple scripting component to an existing application/system (generally in C).

The former is where Corona SDK lives. Other systems live here as well (e.g World of Warcraft, Roblox, etc). In these types of deployments, the developer is required to work within the eco-system.  

Most rocks can be found on GitHub. If you’re looking for specific functionality, you’ll need to hand pick those that you need, making sure that they require no dependencies or compilation. 

If you want to work with 3rd party/external modules, then it’s best to search for “pure Lua” modules. Often these modules will require no more than what is exposed in Lua via Corona SDK. But it will always be hit or miss.

Cheers.

That is correct, however I am talking about source-only rocks. Actually I am simply seeking confirmation whether setting my described behavior is a bug or intended behavior. See again:

Now I am changing lua’s search path so that I can easily include the module:

package.path = ‘lua_modules/share/lua/5.1/?.lua’ … package.path

 

However, after requiring the module:

local log = require(‘coronalog’)

 

Corona Simulator gives me the following error:

ERROR: Runtime error

module ‘coronalog’ not found:

   no field package.preload[‘coronalog’]

   no file ‘lua_modules/share/lua/5.1/coronalog.lua’

   …

 

In the stack trace you can see that the search path was modified correctly and Corona’s lua interpreter is actually trying to load from the correct path, but is still unable to load.

 

Again, lua_modules/share/lua/5.1/coronalog.lua is the correct path relative to my Corona project folder. lua_modules is a sub-folder in there, it is no system directory!

 

So, is this a bug or a feature request?

It’s an intended and sometimes required behavior because of vendor rules (Apple, Google, etc.).

If you’re interested in the specifics I can go into more detail. But to make it short, C is the driver, not Lua. You’re confusing the use case. You won’t be able to change the package path, because that’s not where the control is taking place.

You can submit a feature request here: http://feedback.coronalabs.com/forums/188732-corona-sdk-feature-requests-feedback

Cheers.

@ tyrondis

If you do a print(package.path), does it actually give you what you expect to see? (Before and after extending it.) Or are most of the interesting paths absolute, rather than relative? (Not sure what platform you’re looking at.) Also, in your actual code, are you separating them? From your output message it would seem so, but your example doesn’t have the semi-colon.

If it’s a matter of absolutizing the path, maybe tap32’s post here would help.

I may not have all the technical details straight, but I don’t believe you’ll ever be able to do this. Corona uses it’s own localized instance of Lua (this is the part where I’m making assumptions, so feel free to correct me @CoronaLabs). You can run the simulator and create builds without installing lua on your development machine, so installing modules via luarocks is not possible.

That said, luarocks support would be a feature request I’d get behind big time. But it may not be feasible as it could make the product impossible to support for the engineers in the way Corona users are accustomed to.

Jason is right. Corona SDK has Lua built in. We do not use the installed version of Lua. To work on a device we have to include Lua as part of the app. We have to use a predictable version. We are not going to traverse any installed version of Lua’s paths.

Code generated out of LuaRocks might be usable if you include it in your Corona Project Path and the code is compatible with the version of Lua we are using (5.1 I think).

Rob

Maybe you misunderstood me. I am totally aware that Corona SDK has Lua built in. I am not referencing luarocks outside of my project’s source code. 

$ luarocks install --tree lua_modules coronalog

installs the rock’s content (which is lua source code) in a subdirectory lua_modules in my Corona project, not in some system directory. Still I need to tell lua to search modules in that subdirectory by setting package.path. Corona even is able to resolve the path correctly, as we can see in the stack trace, yet it does complain that the file does not exist.

@tyrondis: if coronalog.lua gets placed inside of a lua_modules subdirectory of your Corona project, then you should be able to require it in by calling

local coronalog = require("lua\_modules.coronalog")

But I think I understand - you want to simply be able to call

local coronalog = require("coronalog")

This may not be precisely what you’re looking for, but if you are on OS X, then you can place modules in the Simulator’s “plugins” folder found here:

~/Library/Application Support/Corona/Simulator/Plugins

and be able to require them in as if they were native libraries. For example, I placed a test.lua file in there, required it by calling

local test = require("test")

and it worked as expected. Perhaps that’s where you should install your luarocks files. Keep in mind that this is outside the recommended user behavior, so tread carefully - infringing on SDK namespaces in that folder could throw things out of whack, and future SDK changes could also make this workaround unstable. I also haven’t tested building for device using files placed in that directory, so I can’t speak to any weirdness that may occur when you do.

But I’m still not sure I completely understand your request. To may way of thinking this seems like a lot of hoops to jump through just to get a Lua module in your project. But different strokes for different folks. :slight_smile: Hope I’ve managed to help a little bit at least. :slight_smile:

Jason have you tried that technique with device builds?

Rob

@Rob: I had not tried it before - I could only vouch that it worked in the simulator. I made an iOS device build and it definitely  does not work on device. My bad for suggesting a hacky workaround in the first place. ¯_(ツ)_/¯

It is certainly overkill for just one module. But this was just for me to try if it works. If you have multiple modules loaded from luarocks with interdependencies, they need to be able to resolve each other. And you cannot modify their source to look in a different path.

I believe also that LuaRocks not only has dependencies to deal with, but some rocks actually need to be compiled against other system components (which LuaRocks handles on install).

As you know, Lua has two major use cases; as a stand-alone interpreter, and/or a layer to expose a simple scripting component to an existing application/system (generally in C).

The former is where Corona SDK lives. Other systems live here as well (e.g World of Warcraft, Roblox, etc). In these types of deployments, the developer is required to work within the eco-system.  

Most rocks can be found on GitHub. If you’re looking for specific functionality, you’ll need to hand pick those that you need, making sure that they require no dependencies or compilation. 

If you want to work with 3rd party/external modules, then it’s best to search for “pure Lua” modules. Often these modules will require no more than what is exposed in Lua via Corona SDK. But it will always be hit or miss.

Cheers.