On Tue, Dec 21, 2010 at 7:37 PM, Alexander Gladysh <[email protected]> wrote: > On Tue, Dec 21, 2010 at 23:49, Cosmin Apreutesei > <[email protected]> wrote: >>> -- copy_directories copy lib/* directories to /usr/local/lib/lua/5.1/ >>> instead of rock directory > >>> LR Team position: this is a feature > >>> Solution: clench teeth and don't ever use lib/ directory. > >> Isn't that where C modules are placed? What's wrong with it? AFAIU >> it's a feature as you can point package.cpath to it and forget how the >> modules got there (i.e. don't have to load luarocks.require). > > That's one more reason why we need issue tracker — context gets lost. > > To put modules to /usr/local/lib/lua/5.1/, one should use build.install.lib > > The build.copy_directories is *documented* to put files in the "rock > directory". IMO, it must do this and no more.
And it does put them there. It does not say anywhere that LuaRocks _keeps_ them there. ;) Really, copy_directories was a quick and dirty way to add directories such as "doc" and "samples" to rocks, added by request. I never thought that should be really done that way (some people even wanted the entire source code to the rocks to be shipped in the rock directory), as I thought we should have had standardized directories for this kind of things, maybe even a way to get a unified documentation for rocks akin to manpages, but then how to standardize things in the Lua world? Each package had docs shipped their own way anyway, so I just let developers drop it there however they saw fit. I didn't add build.install.docs and the like because first it would be docs, then samples, then tests, then who-knows-what and a big difference is that the other entries in build.install.* are _managed_ by LuaRocks while these other ones aren't. Yes, you shouldn't ever use lua/ and lib/ in a rock dir for stuff which aren't Lua modules and Lua C modules (which should end up in the package.path/package.cpath locations anyway). You also shouldn't drop your own files called rock_manifest there, either. If you're not using the standard variables such as $(LIBDIR) and $(LUADIR) to install modules, I can't guarantee much. Thanks to this kind of underspecification I was able to change the format of the tree from LuaRocks 1 to LuaRocks 2 without a lot of pain going on. If LR starts assuming the rockspec can do just about anything with the structure of a rock, we'll be very limited with regard to future changes. Or we can just not care and break everything. Not my style, but a popular approach. >>> -- No support for metadata in rockspecs. I need to be able to put >>> "x-something" fields anywhere in the tree. (Have a fix in Steve's repo.) > >> I thought you can put anything in rockspecs. If not, I need that too. > > No, rockspec files are strictly validated, even the "unknown" fields. > I find it a little strange — I always thought that the idiom was to > ignore the unknown fields. That's a feature which is very useful for me as it catches mistakes I often make, but others may think that "LuaRocks is trying to outsmart the user" or stuff like that. LuaRocks is not designed to be a low-level Unix tool like cat or grep. It tries its best to be a friendly tool for users of Lua modules. Sadly, it seems I'm failing. > But current behaviour is OK for me, it has its positive sides. Just > give me a legitimate way to place my metadata. One could think of many ways to do this (separate metadata file, parsed comments, use of the extensible 'build' section, etc), but you're expecting one very specific way: you want your metadata to be placed inside the specific subtables, added as additional fields and ignored by the validator. That's quite different from "just give me a legitimate way to place my metadata." I never said I wouldn't ever do this, I just needed time to think over this issue (as your "x-something" method has its downsides as well: external tools crop up with their own extensions, which lead to managing conflicts and possible fragmentation of the format -- think of MIME types where you see more "x-something" entries than registered ones). I can just fulfill your request quickly and forget about it, and then one year from now someone will point out an obvious flaw and complain they're clenching their teeth about the behavior of the tool. >>> -- Each time when I ask if I can help somehow to get my feature requests >>> done, >>> I get silence in answer. > >> I'm sure that if you fork the repo, do your fixes and then push it >> back then your changes will be accepted if they make sense. > > I'm not so sure — from what Hisham says, I get a feeling that a few of > my "itches" do seriously contradict with his vision of the project. > That is not a problem and is expected. Hisham is the maintainer, and > I'm merely a user with unusual workflow. A bit of history to give context to the whole "vision" thing: LuaRocks was envisioned by André Carregal from the Kepler Project. I was hired to design and implement it. So, you see, the main requirement for LuaRocks for it to be a manager for Lua modules that was be able to build and install Kepler (which was Xavante + CGILua + a number of support modules). The "weird" behavior of supporting multiple simultaneous versions was another major requirement, because back then the Kepler people went through a lot of pain with API breakage in non-Kepler stuff they depended on like LuaSocket which was still stablizing at the time. Different modules progressed at different paces and it wasn't feasible to make everyone port to new APIs in lockstep. LuaRocks achieved its goal, and eventually it became able to build and install all of Kepler, up to the point that it wasn't necessary to have a Kepler tarball/installer anymore. For that goal to be reached I had to make some concessions to add features that, in my view, go beyond the notion of a manager for Lua modules. It had to install bin/ files, so that the Kepler launchers could be installed. It had to run a post-install hook in order to configure Xavante. A few more of those and LuaRocks would become a full-featured package manager, something I never designed it to be. With the termination of the funded project in Rio, the Kepler developers went each their own way. Some of us tried to commit ourselves to keep maintaing our "pet" projects in our spare time. I think LuaRocks is an important project (or rather, it is a project that tries to fill an important gap) so I try to keep it going in parallel with the other projects I have, plus of course my day job. My vision of the project is simple: LuaRocks is a manager for Lua modules and I'm trying to make it a nice little tool that does that job well, so that whenever people need to add some batteries to Lua they can "luarocks install luasocket" and then "require 'socket'" and be happy. I don't want it to grow in scope -- actually right now I'd prefer it to reduce in scope: handling fs operations using both Lua modules and command-line tools (in various combinations) makes proper testing near impossible, though it was a good idea at the time to have something that would run on most places without a lot of bootstrapping. I'm not spending much time in new features and I think it's important to keep it stable for long periods so that module authors can trust that it's worth their time to learn how to write a rockspec. Maybe Steve's "lake" will be the ultimate Lua-based build tool that will solve everyone's problems. Me, I'd be happy to have build.type = "lake" and just let LuaRocks require "lake" and hand over the environment. I added the "builtin" build.type because I had to go through too many rusty Makefiles from Kepler that had a ton of variables just to build an .so file, but I was aware that features like that would give the wrong "and-I'll-make-you-coffee-too" impression. > I have no problem with implementing my itch myself or by the workpower > of my team (when we have time), that is our itch, after all. > > But before doing this, I would like to get a consensus on what the > solution should be. > > Otherwise, if my solution is not accepted (because it goes against a > spirit of the project), I will get a fork. > > I have no problem with rejects due to quality of implementation and > such, of course — we always can fix that. > > I have no manpower to maintain a fork of LuaRocks and I do not want my > rocks to live in a different not-quite-compatible ecosystem. If I have > to do that, I'm better of to use debian packets. I don't know what's the best answer in your case. I, like every software author, like to see my work being actively used and your feedback has had a lot of positive effects. On the other hand, it's not up to me to say if LuaRocks is a good fit for your project. If my pace of development is too slow and you have to "clench your teeth" a lot, then I'm sorry, there's nothing I can do about it right now. Here I am spending a few hours of my evening to get these emails responded. I try my best to be a good mantainer within the amount of dedication I'm willing to provide to this project, and I know it is not much. For this very reason, I don't go out encouraging people to submit new features. While everybody loves features and I do too, once they're in, it's up to me to keep maintaining them. I've already given up on actively maintaning some things such as Windows support (which I used to do personally when I was working for Kepler -- see the crappy INSTALL.BAT I'm guilty of, for example) but now I just count with the occasional help from Fabio and reports from this mailing list. I've been part of a project before where one specific set of features was enthusiastically added by a contributor, maintained for a while and then set aside once that user's need went away and then I had to keep adding those features into consideration every time I made a change (and I often make a poor job about this, see the post_install problem in LuaRocks) and I couldn't take the feature away either. Balancing between avoiding situations like this and hindering the progress of a project is hard. I guess when that becomes too unbalanced people just fork the project anyway. I think I'd probably hand over the project before reaching that point, though. -- Hisham _______________________________________________ Luarocks-developers mailing list [email protected] http://lists.luaforge.net/cgi-bin/mailman/listinfo/luarocks-developers
