On 5 October 2015 at 13:48, Eric Sproul <[email protected]> wrote: > Hello Hisham, > Thanks for answering my questions, this is all helpful info. > Followups in-line below. > > On Sat, Oct 3, 2015 at 2:37 PM, Hisham <[email protected]> wrote: >> On 2 October 2015 at 15:07, Eric Sproul <[email protected]> wrote: >>> What I'm >>> wondering about is the function of the manifest file, >> >> Serving as a database for installed packages, so that both `luarocks` >> command-line commands work (i.e., can list what's already installed >> and resolve dependencies) and the optional "luarocks.loader" package >> loader is able to resolve dependencies. > > OK, so that means multiple packages must share the manifest file for > the system tree that they deliver into.
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. >>> and whether >>> luarocks supports a concept like Perl's MakeMaker "pure install", >>> which avoids creating a local log of what was installed. >> >> No, but one can do a self-contained install using --tree to point to >> an arbitrary directory, ensuring all changes are self-contained. > > Understood; I'd actually discovered the --tree option after my > original post. :) > >> There are several approaches that could be used here. One of them >> would be to use luarocks strictly as a build tool, have it generate >> .rock files (they are relocatable by design) and then extract their >> contents (they are a zip file) and produce native packages. This is a >> mechanically automatable process. Look at flags such as --tree, >> --deps-mode and the `luarocks pack` and `luarocks unpack` commands. > > Can LuaRocks do self-contained dependencies, a la npm? In the node.js > world, we deliver packages of node modules where their specific > dependencies are co-located with the packaged module, so that multiple > dependent versions can be installed and won't conflict. 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. >> A downside is that users won't be able to use LuaRocks themselves (ie, >> including their own rocks installed in their home directories and >> having those point to dependency rocks installed system-wide). A way >> to solve this is to install files with your tool mirroring the setup >> of files as installed by LuaRocks and then run `luarocks-admin >> make-manifest` to regenerate the global manifest (in your post-install >> hook or equivalent). > > Oh, so a manifest can be rebuilt from the on-disk content in a tree? > That's nice. 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. >> Ubuntu packages are the Debian packages, using a methodology which >> predates LuaRocks. Homebrew, for Mac OSX, for instance, currently >> bundles LuaRocks with their Lua package, AFAIK. > > I see. Well, I'm used to breaking new ground, and I think I have some > avenues to explore now. Nice — if you have any other questions don't hesitate to contact us! -- Hisham ------------------------------------------------------------------------------ _______________________________________________ Luarocks-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/luarocks-developers
