2015-05-27 5:43 GMT+02:00 Alloyed <[email protected]>: > > > On 05/25/2015 06:47 PM, XIAO Qi wrote: >> Hi all, >> >> Somewhat a newcomer to the Lua community, I am doing a Summer of Code >> project on LuaRocks, the luarocks addon system. Basically, the system >> will allow enable addons that can plug into the building process of >> rocks and do basically arbitrary things. See the SoC ideas page [1] or >> Hisham's talk [2] for more. >> >> However, to make the life of addon developers easier as well as to >> prevent the addons from destroying the world, we first have to define >> an API for the addons to interact with luarocks internals. The API >> would, of course, depend on what kind of addons we have in vision. >> Hence I would like to have your suggestions on two questions: >> >> 1) As a rock developer, what kind of addons would you like to have? >> >> 2) As a prospective addon developer, which parts of LuaRocks should be >> available to plug into? >> >> As an example, say as a rock developer, I wish to have addons that do >> testing after building the rock. And in turn, as a prospective >> developer for the testing addon, I would like to have the list of >> modules available to the addon (in the case of the "builtin" backend), >> and would like to report test failures and possibly prevent the rock >> from installing. >> >> 1. http://www.lua.inf.puc-rio.br/gsoc/ideas2015.html#luarocks >> 2. http://luaconf.ru/#Muhammad >> > > As a place you might want to crib inspiration from when it comes to API > design is leiningen[1], Clojure's package manager. IMO it handles the > idea of an exstensible package manager much better than anything else > I've used. > > To start, lein has a built-in notion of profiles[2][3], which are > effectively configuration "overlays". instead of having an explicit > build_dependencies key or anything like that, you would instead create a > "build" profile, and then list your dependencies as part of that. Since > any key can be part of a profile, you can also change how your code is > run, what environment variables are passed to it, etc, and since a > profile can have any name you can define your own custom profiles, e.g > for a lua5.1 configuration, a version of your project that only uses lua > code, etc. > > The API leiningen ends up exposing via plugins[4] is actually very > small: plugins rarely change the functionality of existing leingingen > commands, they either add their own profiles or define their own > commands, which can then use your profiles to configure themselves. > >
Hi, much thanks! That sounds very interesting. Point it out if I am wrong, but as I see it, profiles can only do as much as you can manually do with the configurations. For instance, to make it possible to write a "test" profile, you should be able to write a lein configuration that does testing in the first place. So I suppose lein configurations must be pretty powerful. In contrast, with LuaRocks it seems impossible to say "do testing after build" using rockspecs, other than resorting to the make or cmake backend. So to conclude, if we are to follow lein, we must introduce more flexibilities in rockspec first. That is actually a very interesting idea... > 1. https://github.com/technomancy/leiningen > 2. > https://github.com/technomancy/leiningen/blob/master/sample.project.clj#L148 > 3. https://github.com/technomancy/leiningen/blob/master/doc/PROFILES.md > 4. https://github.com/technomancy/leiningen/blob/master/doc/PLUGINS.md > > ------------------------------------------------------------------------------ > _______________________________________________ > Luarocks-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/luarocks-developers -- Best regards, 肖骐 XIAO Qi ------------------------------------------------------------------------------ _______________________________________________ Luarocks-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/luarocks-developers
