On Mon, Oct 5, 2015 at 12:55 PM, Hisham <h...@hisham.hm> wrote: > A rock installed in a local tree can refer to rocks installed in the > system tree. All trees under rocks_trees are scanned, so it does not > have to be all under one tree necessarily.
Good to know. I'm not sure whether our use case justifies allowing end users to manage their own rocks. We may end up using it just as a package build tool, like you suggested. > npm replicates dependencies, we don't. We handle multiple dependent > versions differently. We rename conflicting versions but the > luarocks.loader can find them via the original names when using > require(), based on the dependency graph of previously loaded modules. Interesting. I'm not sure what the implications will be for our packaging scheme if this arises in our usage. I'll make a note of this though. > Each rock has its own rock_manifest inside > lib/luarocks/5.<x>/rocks/<rock_name>/<version>/ — the global manifest > aggregates this info and is generated from those files. I see, thanks. Eric ------------------------------------------------------------------------------ _______________________________________________ Luarocks-developers mailing list Luarocks-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/luarocks-developers
