rockspec format fix ?

[tst2005]

Hello,

I played to make all-in-one file for telescope (a tsc embeding all dependencies). I never found the built.type = "none". I'm often found the format like I changed.

Let me know your opinion. Best Regards,

[britzl]

@tst2005 I am not an expert on Luarocks and the rockspec format, but why is it necessary to change type to "builtin"? The "none" type is described as "Indicates that there is no build to perform " (https://github.com/luarocks/luarocks/wiki/Rockspec-format#none) and surely that works for Telescope?

[tst2005]

@britzl Hmm... I did that years ago! I did it for the need to have a list of file content to install for my external thirdparty tool. I'm agree with you, none is a valid type. but in 2016 I'm not sure I found the proper rockspec documentation. I probably suggest builtin type just because I had seen it everywhere else in similar case.

Unfortunatly I don't have time to test the different behavior to see what is the best.

[britzl]

Thanks, I was just curious about the choice.

[tst2005]

In fact, at the origin, I did it not to provide a telescope package for luarocks !

My goal was to generate a uniq telescope executable file with all sub-modules embeded.

I had made a tool to take all files of a project and build an all-in-one file.

It was the best way I found to make lua code with lot of modules, but use/distribute the result in one file (one module embedding all sub-modules or one executable script embedding all modules). I needed a list of "module.name" + "/path/to/file.lua" I decided to use the rockspec file because most of project have one. This approach only run for project that does not require compilation.

I try to make an all-in-one file for some projects After that I decided to push the idea to the next step : provide bundles! My definition of a bundle : bundle = 1 all-in-file + 1 information-file

I discover the need to ask what is contained inside the bundle and ideally deals with different versions... A bundle can also be huge. It seems inefficient to load a huge bundle to check the version and decide it will not used (but stay in memory).

I defined my own simple format : each all-in-one module will also have his own information module. For a "foo" module (foo.lua or foo/init.lua), I also create a "foo.__bundle" module (foo/__bundle.luafile). I choose the make a small one-line file module to put information about a"foo"module in a"foo.__bundle"` module.

The results were here. It also contains a personal solution to switch between different module implementations.

For sample lua -l for.json.use.cjson is almost equal to lua -e 'json = require "cjson"

$ lua -l for.json.use.json ...
$ lua -l for.json.use.cjson ...
$ lua -l for.json.use.lunajson ...
$ lua -l for.json.use.default ...

$ lua -l lfs ...
$ lua -l for.lfs.use.syscall.lfs ...

$ lua -l lpeg ...
$ lua -l for.lpeg.use.lulpeg ...

$ lua -l for.class.use.mini.class ...

I hope you will not regret to be curious ! :-D

[britzl]

I hope you will not regret to be curious ! :-D

Thank you for explaining the reasoning behind it! 👍