lua-users home
lua-l archive

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


On 8 September 2015 at 22:55, Philipp Janda <siffiejoe@gmx.net> wrote:
> Am 08.09.2015 um 22:42 schröbte Coda Highland:
>>
>>
>> The way most packaging systems handle this is to give the distinct
>> versions distinct package names instead of trying to use the version
>> number. For example, in Ubuntu, Python libraries that support both 2
>> and 3 are shipped as "python-xxx" and "python3-xxx" (e.g.
>> "python-cairo" vs. "python3-cairo").
>>
>> So you might have mylib_51 version 1.0.2-1, mylib_52 version 1.0.2-1,
>> and mylib_53 version 1.0.2-1 -- and, if your 5.1 version isn't
>> LuaJIT-compatible for whatever reason, perhaps mylib_lj version
>> 1.0.2-1 or similar.
>
>
> That's difficult, because LuaRocks doesn't support alternative dependencies,
> so something like
>     dependencies = {
>       "mylib_51 >= 1.0 | mylib_52 >= 1.0 | mylib_53 >= 1.0"
>     }
> won't work.
>
> On the other hand LuaRocks does support separate manifests for the different
> Lua versions, so that `luarocks-5.1 install mylib` will install the latest
> mylib version that's compatible with Lua 5.1.

I did not know this, we have indeed:

https://luarocks.org/manifest-5.1
https://luarocks.org/manifest-5.2
https://luarocks.org/manifest-5.3

I could just use the first manifest, which only report the cqueues
version relevant for Lua 5.1.

> There's nothing wrong with taking advantage of that fact. It's unfortunate
> though that ULua currently does things differently.

Well, I strived to design my package system to be as simple as
possible: 1 to 1 correspondence between module and package, package is
just a Lua module + tiny metadata and paths conventions, semantic
versioning....this results in a good experience for both users and
maintainers.

The price to pay for this is the necessity follow some rules. My build
system enforces them when building/packing stuff from Luarock to ULua
but some cases require further attention.

Stefano