On Wed, Dec 22, 2010 at 03:07, Hisham <[email protected]> wrote: > 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. >> 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. ;) Um. As long as in the end the file is not there, the documentation is wrong. > 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. This should be documented at the very least. > 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. I do not understand this position. Why copy_directories is mixed up with build.install.*? Can't LR just copy verbatim whatever is listed in copy_directories and be done with it? BTW, I'd like to highlight the use-cases for copy_directories: 1. Custom non-Lua data: html, javascript, nginx configs etc. Legitimate use-case for everyone. 2. Private Lua code. Roughly: lua -e package.path = package.path .. ";$(luarocks show --rock-dir <name>)/src/lua/?.lua" my-tool.lua The my-tool uses some implementation code that should not be visible for other modules that use LuaRocks. >>>> -- 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. No, this is not the case about outsmarting, IMO. Here, LR does what it was told to do. >> 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. Please note that I did not ask you to fix this particular issue ASAP. No problem with thinking it over. One note: Steve's patch with top-level metadata field is not relevant, I come to think. It is the same as to store metadata in the other file. The x-something solution is better (for me) because it allows to store the metadata near the data it is related to. And, you're right about the downsides — the question is, are those downsides bad enough to be show-stoppers or not. But, anyway, if you say no, I can invert the control, and generate a rockspec from the file with metadata... (much more work for me than enabling x-something in the rockspec though, but that is my problem...) >>>> -- 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: Just in case: 'this "vision" thing' is not a criticism. You're acting as it is expected for the maintainer. > 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. I believe that LuaRocks is very important for Lua community indeed. > 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. This may be a good idea as long as I'll be able to install Lua modules without lake (also, I'd drop "make" etc. types — but this can harm adoption...) >> 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. Thanks. > On the other hand, it's > not up to me to say if LuaRocks is a good fit for your project. Nor you're expected to. :-) The responsibility for the decision is solely mine. My projects nowadays are mostly Lua code (lots and lots of it, most is generated) and some JS/HTML/resources etc. stuff. And a few our own C modules. And third party Lua module dependencies, most in C. All code is for Linux (even stricter, for Ubuntu or, maybe, Debian as well). I needed a deployment system. LuaRocks is good at installing Lua code and I have experience with working with it — so I chose it. Another option is to use debian packets, but no one in my team had hands-on experience creating a deployment system with them, and the thing should be done ASAP. (Also, from a glance, there is a lot more work to create a proper debian packet than to create a LR packet) So I chose LR. And I do not regret that. If most of the issues I listed here are resolved that way or the other, I think, that would be sufficient to build feature-complete deployment system (specific for my needs) on top of the LR. Even without that we cope well enough. > 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. Thank you, Hisham. There is nothing to be sorry about. You're working for free, in your own time. Again, I'm not pushing you to fix anything ASAP (well, I had for a couple of things, but I've withdrawn that — and I should not have said that in the first place). I work on commercial project, you do your work on LR for free. I'll be happy if 2.0.4 will be released, but if the problems with 2.0.3 will start to be too bad for us, we'll just switch to the Git HEAD. > 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. It is enough. > 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. No problem with that. Project maintainer must be conservative — that is half of the job. > Balancing between avoiding situations like this and hindering the > progress of a project is hard. I think that, perhaps, the progress for a project such as LR should count not torwards number features, but torwards balance of these features. Now we seem to be in the middle between a "manager for Lua modules" and a "generic package manager". From my *heavily biased* perspective, there is a small push needed to make LR a "generic enough package manager, excellent for Lua-related stuff, good enough otherwise". And turning it to just a manager for Lua modules seem to require more incompatible changes than that. But I do not have whole picture. > 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. Please don't hand over it — Lua community is too dependent on LuaRocks. Alexander. _______________________________________________ Luarocks-developers mailing list [email protected] http://lists.luaforge.net/cgi-bin/mailman/listinfo/luarocks-developers
