Hi,
I'm struggling with a design issue regarding multiple local trees, and
I'd like to hear your opinions.
Currently, LuaRocks supports multiple local trees, as in:
rocks_trees = {
home.."/.luarocks",
"/usr/local"
}
This means LR can load rocks installed in either of these two local
trees. In fact, with such a configuration, commands such as "luarocks
list" and "luarocks show" will show rocks installed in both trees and
the luarocks; "luarocks path" produces variables with both trees.
However, commands which _manipulate_ the trees do not take all trees
into account, but only a single tree at a time. So, a command such as
"luarocks remove lpeg" reports "Error: Could not find rock 'lpeg' in
local tree" if the rock is not installed in the "default tree", which
is the last one from the list (one has to use either --local,
cfg.local_by_default=true or --tree=<path> to override which is the
default tree). [Older versions of LuaRocks used to autodetect
permissions to supposedly do the right thing whether the users used
"luarocks install foo" or "sudo luarocks install foo" to install in
the home dir or system-wide, but that only seemed to confuse users.]
This was done this way to avoid leaving local trees in an inconsistent
state: for example, one installs "foo" system-wide, then "bar" (which
depends on "foo") home-wide, and then they reconfigure their
config.lua to stop using the system-wide tree, and then the "bar" rock
from the home tree stops working.
This has the unfortunate side-effect that if you'll have "missing
dependencies" reported when trying to install a package locally even
though the dependencies are already installed system-wide. In its
current behavior, LuaRocks will behave as if the system-wide rock
didn't exist and will try to install another copy locally.
Users already complained about this behavior:
https://github.com/keplerproject/luarocks/pull/89
So, well, it looks like we can't have the cake and eat it too. Either
we support using dependencies from multiple trees, or we protect trees
from potentially missing dependencies as rocks are removed from a
system-wide tree.
I'm not sure if simply reading all trees as implemented in the above
pull request is the right thing to do, as there seems to be a
hierarchy in trees -- it seems logical to me that a system-wide rock
cannot have a dependency satisfied by a home-tree rock, which could
happen with the above patch if the user happens to have write
permissions to both trees.
So, any thoughts or opinions on the matter?
-- Hisham
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Luarocks-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/luarocks-developers
