On Wed, Dec 22, 2010 at 02:02, Hisham <[email protected]> wrote: > On Tue, Dec 21, 2010 at 2:15 PM, Alexander Gladysh <[email protected]> wrote:
>> I thought, I should collect all my "feature requests" in a single >> place, so they would not get lost in the noise. >> Hisham, maybe LR needs an issue tracker? What if I use one on github? > Some people started using it already, so feel free to do so. I get > emails when things are posted there. OK, will do. >> -- luarocks show (and maybe others) do not print errors to stderr. >> LR Team position: to be fixed in 2.0.5 >> Solution: clench teeth and use workarounds. > The reason why I never worried about stdout vs. stderr is because the > output of LuaRocks was never designed to be machine-processed. I can > audit the code to find every occurrence of print and evaluate whether > it should be changed to io.stderr:write (and patches are welcome in > that regard), but that won't make the output of LuaRocks entirely > predictable anyway, since it has various modes of operation depending > on which external tools are used, and I never committed to keep the > output identical from version to version, since it is designed for > interactive users to read, not to be fed to scripts. I don't plan to do any machine processing in this particular case. I just need $(luarocks show --rock-dir)/bla/bla and similar commands to show error message to user if rock is not found. I'll try to produce a patch when I have time. (If someone will get to that ahead of me, tell me :-) ) >> -- Can't get a list of files that would be packed in a rocks for a rockspec >> without building it >> LR Team position: impossible with the current codebase >> Solution: clench teeth and write my own code > Why should you clench teeth on this? Because I'd like to write this in LR environment, not to write ad-hoc code which will break on the next release. But I do not think this is easily doable at this point, so nevermind. > Was I expected to have written > the code such as to make it easy to produce a manifest of rocks > without building them without ever knowing that someone would need a > feature? (Especially taking into account that one of the earliest > LuaRocks requirements was to work with third-party build tools such as > make, which render this task impossible anyway.) Sorry, I did not want this to be seen as a criticism of your design. I do not see this as an "expected" feature in a sense of a "must have", just a nice to have one. It would be good to have a library to work with LR data, but this is a task for the (far?) future, not something one would expect to see from the start (or even in 2.0). >> -- LR can't build a rock without installing it into a system >> LR Team position: ??? >> Solution: clench teeth and use luarocks make > That is exactly my position. I don't know what exactly you mean by > that. In my deployment process I need to build a machine-specific rock for another machine. I do not need this rock to be installed on the machine I do deployment from. Furthermore, if this rock would be installed, my code on my machine will break (since, naturally, it contains data/code for the wrong machine). Now I have to remove such rocks from my machine after the deployment. Besides that, I'd like to speedup a bit my deployment process. Extra file operations take time. (I did not do any benchmarks though, so this is a weak argument.) > I've received requests to change the behavior of luarocks make > and split it into two commands, "luarocks make" and "luarocks > make-install", but given your solution I don't think that's what you > are asking for. No, that is not. (This may be related to the git+ssh problem though, but I'm not sure if it is a good solution...) > If what you want is to be able to run "luarocks build" > and get a .rock file without affecting any of your rocks trees, then I > acknowledge the limitation. Yes, this one. > I consider this, however, to be a missing > feature and not a bug. Um, I did not said that this is a bug. Actually, I wrote that all these items are "feature requests". >> -- LR does not allow user to specify a compression ratio when packing a rock >> LR Team position: wontfix, too specific >> Solution: clench teeth and waste CPU and developer time > Or just clench your teeth and use a workaround: try environment > variables such as GZIP and ZIPOPT, or even alias the compressor in > your environment. Using environment variables is a good idea, thank you. >> -- Each time when I ask if I can help somehow to get my feature requests >> done, >> I get silence in answer. >> Solution: I need to see a stomatologist > I'm not sure if I get the joke, but I'm sorry if my feedback is unhelpful. The joke: too much teeth clenching :-) Hisham, you are helpful. Actually, you're one of most responsive opensource project maintainers I work with. I apologize if my original letter was too harsh. (Also, that "clench teeth" joke is not a very good one.) Too much criticism, no praise at all. :-) I just spend too much time working with my deployment system (not a LR fault mostly), and I do not quite like doing that (and I like to rant). There are a couple of (minor enough) issues in LR that annoy me, but, besides that, the system works well. I'm just trying to force it to do what it was not primarily designed for (and, as I said, mostly it copes fine). Thank you, Alexander. _______________________________________________ Luarocks-developers mailing list [email protected] http://lists.luaforge.net/cgi-bin/mailman/listinfo/luarocks-developers
