On Thu, Sep 13, 2012 at 4:26 AM, Ildar Mulyukov <il...@users.sourceforge.net> wrote: > Hi, Hisham, everybody! > > On 11.09.2012 01:25:17, Hisham wrote: >> I'm struggling with a design issue regarding multiple local trees, and >> I'd like to hear your opinions. > > AFAIU, there are one big question and several small technical questions: > 1. How should LR handle multi-trees ? > 2a. How trees should be handled > 2b. How deps should be handled > 2c. How to handle manifest file(s) > > I believe that to answer the 1st question we need to answer another > (simple) question: >> Q: What is LR? > I know a simple answer (from the README): >> a deployment and management system for Lua modules. > Well, this looks very much like a Package Management System (like RPM > or DEB).
Yes, it is a language-oriented, multi-platform package manager. (I guess this definition is wide enough for the class of programs LR is a part of, along with RubyGems, etc) > Ok. Now let's look at some things that may lead us to the right > direction. Those are: $LUA_PATH, RPM/DEB. > > 1. $LUA_PATH (similar to $PATH, $LD_LIBRARY_PATH): > 1. allows access to lua libraries that are placed in multi-trees. > 2a. do not imply any rules on where files should be put. > 2b. do not control dependencies > 2c. do not have/need any cache files (ld.so has ld.so.cache but > that's optional) > 2. RPM/DEB > 1. cannot handle multi-tree (at one shot). > I myself can't remember any other Package Management System > supporting multi-tree. (BSD-ish maybe? I don't know.) > 2a. have rules where to put files (mainly according to FHS(1)) > 2b. strong in controlling deps > 2c. have DB which is mandatory. > > So speaking of LR, if it's a Package Management System, then it > probably shouldn't handle multi-trees in terms of deps checking. PERIOD. I disagree. Just because RPM and DEB don't handle multi-trees (and I'm not even sure they don't, it's been a long time since I last looked at them), it doesn't mean that no pacakge manager can ever have this feature. > But if treating LR as "packaging of what is in $LUA_PATH", then there > could be an alternative design: > 1. LR follows $LUA_PATH and handles multi-tree according to it. > $LUA_CPATH should be taken into account too. > 2a. -||- > 2b. LR shall control deps. > 2c. manifest file existence and placement should be rethought. > > Need to elaborate further. But for now what do you think? Item 1 would be a great idea if LUA_PATH was not so free-form. We could kind-of guess the LR trees and their precedence from a well-behaved LUA_PATH, but we can't really count on this. On item 2c, we did change that from LuaRocks 1.x to 2.x, in order to make things more controlled and to be compatible with the standard layout expected by vanilla LUA_PATH. I don't think the big challange now is about placement and the manifest really, but rather about defining the behavior of the tool in the presence of multiple configured trees. Some concrete questions: * Should LuaRocks allow the installation of rocks in a tree if its dependencies are installed in another tree? * Should this behavior to be the default? * Should any other configured tree match, or should there be criteria for this "other tree" to be accepted (Example: /usr/local depends on /usr, not vice versa) * How about the user tree? (Scenario: What if the sysadmin uninstalls a rock and breaks the user's tree? Do we care?) -- Hisham ------------------------------------------------------------------------------ Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ Luarocks-developers mailing list Luarocks-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/luarocks-developers
