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. >> -- 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. But current behaviour is OK for me, it has its positive sides. Just give me a legitimate way to place my metadata. >> -- 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. 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'm also open to the suggestions about "sponsoring" in one way or the other for the implementation of my itches by someone else — especially for such features which are not useful for the "open-source community" (as I use LR to work with private code). There are some bureaucracy problems with that, but if someone interested, contact me privately, maybe we can work something out. My budget on such things is not as high as I'd like though... > PS: Your use case for compression options intrigue me -- last time I > used it I had a 486 :) Too many rocks to build on deployment. I'm trying to squeeze out a few fractions of a second from using store compression. (I.e. I'm fine if my *.rock files are just uncompressed tar files.) Alexander. _______________________________________________ Luarocks-developers mailing list [email protected] http://lists.luaforge.net/cgi-bin/mailman/listinfo/luarocks-developers
