 |
lua-l archive |
|
|
||
|
On 27 Feb 2016 12:13, "Enrico Colombini" <erix@erix.it> wrote:
>
> On 27-Feb-16 12:04, Pierre Chapuis wrote:
>>
>> Or you could just package the interpreter, the application and necessary
>> libraries in a way that your users can use. For Windows, it can be as
>> simple as bundling it with Lua Binaries [1] and adding a 2 lines BAT file.
>> You don't even have to compile anything.
>
>
> That's what I was doing some years ago, when there was a single universal Windows runtime (MSVCRT.DLL) and most libraries were available as precompiled DLLs.
> I may be wrong her, (not having been able to use Lua for paid work in the latest years, but getting drop-in precompiled libraries does not currently seem to be that easy.
>
> Besides, distributing the interpreter and the libraries together with each and every Lua program does not strike me as the best solution for all cases.
>
>
>> If you ask your Windows users to install Python, my experience is that
>> they will run away too.
>
>
> Not very reassuring :-)
> My users don't seem to be running away, though. To illustrate the point, just recently I had trouble akin to a Lua library installation with a Python library that was awkward to install on Windows (numpy). In the end, I had the user install another Python interpreter (Anaconda) that had both numpy included and a package manager to easily get the other required libraries.
>
> I be would very glad for a solution to the problem "to run this Lua script, you just have to...".
>
> --
> Enrico
My work on ULua [http://ulua.io] has been motivated by similar concerns.
There is almost an 1 to 1 relationship between modules and packages, so in most case for:
require 'socket'
you just need:
pkg.add('socket')
Stefano