Re: Two types of Lua programmer, or two types of Lua code?

I forgot to mention why I brought up this feature of lit. This is a long-winded way of saying that I agree that there are differences between libraries and applications.

- Libraries want automatic dependency updates without having to re-publish. (preferable using semantic versions so as to not pull in breaking changes, but do include bug fixes.)

- Once published, applications don't want anything to change. If they want to pull in new dependencies, they will publish a new version.

- Libraries are usually just lua code (or maybe native modules), but always just modules/packages.

- Applications sometimes are run with just `lua` or `luajit`, but often are embedded in some framework that provides better integration with the host system and user interface.

Yes both have a name, publisher, version, files, and metadata and can be published using similar mechanisms, but their intent and use differ a lot. I feel luarocks aims mostly towards the library use case. It works for applications that are plain command-line utilities, but not much past that.

On Thu, Feb 25, 2016 at 10:44 AM, Tim Caswell <tim@creationix.com> wrote:

With the lit package manager, you can specify that a published package is an application and tell it what bundling framework to use. Currently this only supports luvi (luajit + libuv + zip asset management in a single binary), but there is no reason it couldn't also support LÖVE, Corona or the other frameworks.

Also to make published application versions stable, lit saves a snapshot of all current dependencies as a git tree hash when publishing. That way if I want to build luvit v2.0.1 I'll always get the exact same set of lua dependencies, even if some of the dependencies have since changed. But when I publish a new version of luvit, it will take a new snapshot of the current dependencies so that I don't need to manually update them. I just need to test to make sure things are working when I publish and they will continue to publish.

Then doing simply `lit make lit://luvit/luvit` will find the latest published luvit release, see it has a tree snapshot of all dependencies, see that it uses a certain version and configuration of luvi, and build a single binary.

-Tim Caswell

On Thu, Feb 25, 2016 at 10:39 AM, Viacheslav Usov <via.usov@gmail.com> wrote:
On Thu, Feb 25, 2016 at 5:09 PM, Coda Highland <chighland@gmail.com> wrote:

It should be noted that its use as a standalone language is
near-exclusively the domain of Linux, where people don't have a
problem installing dependencies. At least on Windows, you're either
going to have to bundle Lua (at which point a rock doesn't make sense)
or write a wrapper app that embeds Lua (at which point a rock doesn't
make sense). Standalone apps distributed as Lua code aren't going to
see traction on Windows, and unless Microsoft themselves starts
deploying Lua, that's not going to change.

This is not about Windows vs Linux. Technically skilled users would have no problem using Lua on Windows. This is about technically skilled users vs consumers. Consumers do not typically use Linux on PCs; Linux is mostly used by consumers in non-PC setups, such as Android phones and tables. How would you go about deploying an all-Lua app on a recent stock Android smartphone?

Cheers,
V.