Fw: Luarocks framework in pkgsrc

["Kamil Rytarowski" <n54%gmx.com@localhost>]

----- Original Message -----
From: Kamil Rytarowski
Sent: 04/05/14 10:24 AM
To: pkgsrc-wip-discuss%lists.sourceforge.net@localhost
Subject: Luarocks framework in pkgsrc
 Hello,

Many Lua packages [1] are maintained through the Luarocks [2] framework.

The packages provide .rockspec, in a json format, that contain all important 
information to:
1) present information, license, project website,
2) fetch sources,
3) present Lua dependencies against Lua generation (currently mostly 5.1, 5.2) 
and other packages,
4) build and install information in a declarative way.

One of the examples for cosmo-14.03.04 [3]:package = "Cosmo"

version = "14.03.04-1"

description = {
 summary = "Safe templates for Lua",
 detailed = [[
Cosmo is a "safe templates" engine. It allows you to fill nested templates, 
providing many of the advantages of Turing-complete template engines, 
without without the downside of allowing arbitrary code in the templates.
 ]],
 license = "MIT/X11",
 homepage = "http://cosmo.luaforge.net";
}

dependencies = { "lpeg >= 0.9" }

source = {
 url = "http://www.keplerproject.org/files/cosmo-14.03.04.tar.gz";
}

build = {
 type = "builtin",
 modules = {
 cosmo = "src/cosmo.lua",
 ["cosmo.fill"] = "src/cosmo/fill.lua",
 ["cosmo.grammar"] = "src/cosmo/grammar.lua",
 },
 copy_directories = { "doc", "samples", "tests" }
}


This implies the fact that venerable Makefiles are partly abandoned, they need 
patching to handle Lua version and Lua directories.

My goal is to add set of Lua packages to pkgsrc and the primary goal was to add 
Sputnik. However the configure (in bash format) files and the Makefiles fired 
from ambush with all their hardcoded parts, missing files in Makefile, etc 
[4]...

Lua packages are usually little depending upon system and they install 
libraries in a format of .lua, .so, documentation and examples.

Possible solutions to add the missing packages to pkgsrc:
1) Rework upstream configure and Makefiles (and try to upstream them with 
pull-requests)
2) Add a compatibility layer of .luarocks used in pkgsrc, that extracts rules 
from .rocks shipped with packages
3) Add luarocks2pkg that generates packages's files for pkgsrc (DESCR, PLIST, 
Makefile..)
4) Leave it as it is and use luarocks the upstream way, not managed in pkgsrc

What solution is the best? Assuming that:
1:
+ No need to introduce changes in the infrastructure of pkgsrc
+ Slowly lower maintaince efforts pushing patches upstream
- Nobody assumes that things won't be broken again
- We will be probably the single vendor using Makefiles

2:
+ Little effort to add new Lua modules
+ Lower maintaince cost of maintaining Lua modules, automatic updates synced 
with upstream
- Add new piece to the infrastructure that needs maintainership
- Need to design and implement a no-code-generation (at least producing files) 
way to handle the .rocks
? No directly static information of a package, what's that and what it needs to 
run (?)

3:
+ Reduce cost of maintainership of Lua packages in pkgsrc
+ No need to introduce changes in the infrastructure
- Need to use additional tools to generage pkgsrc packages
- No ready to use wrapper over .rocks, need to regenerate files

4:
+ no cost of doing anything
- fiasco, delay of problems
- manage duplicated packages with duplicated managers (pkgsrc, upstream system 
distribution, luarocks)

What solution from 1-3 would be the most pkgsrc-way?

Personally, I like (2), however I don't know whether it's possible to do it a 
clean way with no-code-generation? So the problems bring an alternative with 
(3), where (1) is just a monkey work -- with high constant cost of maintaince.

Please show me the right design how to do it for pkgsrc.

With kind regards,

[1] http://luarocks.org/repositories/rocks/
[2] http://luarocks.org/
[3] http://luarocks.org/repositories/rocks/cosmo-14.03.04-1.rockspec
[4] https://github.com/mascarenhas/cosmo/blob/master/configure 
https://github.com/mascarenhas/cosmo/blob/master/Makefile 


----

Hello,
It come to my mind that there is another possible way to manage Lua rocks. Use 
(patch? new .mk?) luarocks to install packages from the fetched .rocks. This 
way needs more evalution and checking.

Quick evaluation, without looking into the luarock construction:
+ stop depending on Makefiles
- extend syntax of our Makefiles for rocks (new keywords?), possibly need to 
evaluate integration with the infrastructure anyway
- maintain and use of external tool, possibly not the upstream way (whether we 
care this time?)
- need to follow dependencies in Makefile anyway (like 
lua-lpeg>some-version:../../some-path/some-pkg).. since luarocks will be 
intented to just build and install

Regards,

------------------------------------------------------------------------------
_______________________________________________
pkgsrc-wip-discuss mailing list
pkgsrc-wip-discuss%lists.sourceforge.net@localhost
https://lists.sourceforge.net/lists/listinfo/pkgsrc-wip-discuss