On 14 August 2013 13:44, steve donovan <steve.j.dono...@gmail.com> wrote: > On Wed, Aug 14, 2013 at 3:40 PM, Peter Drahoš <drah...@gmail.com> wrote: >> >> - Author/Maintainer entries and other useful metadata > > It seems a small thing, but this is very important. When I package someone > else's code, I don't want to accidentally claim to be the author! I am just > looking after a rockspec, a humble but very useful role.
We do have 'homepage' and 'maintainer' for these roles. 'author' implies a single-person effort; 'homepage' is more inclusive and the URL may then point to proper credits for the upstream code. This is documented in http://luarocks.org/en/Rockspec_format -- perhaps deprecate 'maintainer' and use 'rockspec_maintainer' instead? >> - Provided functionality as in LuaDist so modules can replace other >> modules transparently, e.g. luajit provides lua and bitop > > > 'provides' is a good concept. To me this is related to alternative > dependencies, since one can merely require something that provides a given > feature. Agreed, 'provides' and 'alternative dependencies' are closely related, and useful features to have. >> - Optional dependencies, as mentioned many times before > > > That's a useful thing (related to build-time dependencies). For instance, > strictly speaking Lake only needs LuaFileSystem, but it acquires extra super > powers if luaposix or winapi are available. But if a third package depends on Lake, can it assume that it has the super powers? Optional dependencies are cool but have to be implemented carefully, to avoid a combinatorial explosion of possibilities for an author to consider in their dependency tree. Also, some users want optional dependencies to be pulled, others want them to be ignored, and yet others will want only some of them; there are UX considerations to be made. (Yes, there are command-line tool authors who care about UX too :) ) >> - Marking external dependencies as optional, LuaDist or any other package >> manager can install them automatically > > > So the maintainer can go to the trouble of specifying the Debian, Fedora or > whatever packages that would satisfy the external need. Extra work, but > users will appreciate this. Currently LR cannot make fine distinctions > about the platform, e.g. Linux can be .deb, .rpm, etc. You two guys mentioned two different things. Marking external deps as optional falls under the same category as the previous item (cool but has to be done right -- in particular, those things will add some weight to the build section of rockspecs too, as flags etc become conditional). About the second thing Steve mentioned, of adding platform-specific hints on how to get the external deps, I'm not sold on the idea. We already try to perform some agnostic detection and mark them with generic names. An external tool such as LuaDist (or other) could keep its own table matching those names to its own non-Lua packages (or to distro packages). Might be a nicer approach. >> - Specification and running of tests > > There are so many testing frameworks! These can be 'test-time' dependencies. That's a good idea! >> - Documentation install destinations so it can be accessible through >> require (or by other means) > > > Again, so many conventions. > >> >> - Rockspec module metadata install destination and possible accessibility >> by require (or by other means) > > > We've talked about providing an easier way for scripts to query LR for > package information. I think it can be done with a package which can itself > be installed with LuaRocks. Eventually, LR needs to become "reentrant" so it can be used as a library. I want this to happen at some point, but it will take a while, though. A small library for querying such data could be made in the meantime, though. >> - Storing component information metadata (eg. installed data files, >> documentation files, module files, executable files …) > > I'm reading this also as meaning associated data like stylesheets and so > forth. Currently LDoc solves this by making its templates and stylesheets > Lua modules, which is a fine solution if you design for it. It doesn't work > that well for binary assets like images. Assets can be copied into the rocks > tree, but there's no straightforward way to get at them. Ideally we want a > way that doesn't need specific LR hacks in the code itself! Adding a feature to deploy data files to arbitrary subdirs is the easy part; the hard part is to make apps/modules find their data files even though LR installs all packages as relocatable -- ie, apps/modules can't count on hardcoded paths. So that second part inevitably requires cooperation from the app/module itself. (Daydreaming out loud: perhaps it would be nice to have a module for loading data files that abstracts away the hard work of finding files could be a good idea; it could know about luarocks, but it also could know about traditional Unix paths like /usr/share, and perhaps even be taught some rpath-type tricks (extrapolating based on location of the script itself) on Windows... and then apps/modules could do stuff like `local data = require("data"); local icon = data.path("myapp", "icon.png")` or even data.open, which would even allow for adding support for loading resources from bundle files and the like... but I digress from the rockspec discussion!) Well, I think the first step would be to start a new branch on github with incompatible features and bump the rockspec_version number. I think a starting point would be to add some smartness to type_checker, so we can lint rockspecs and make sure that those using new features are marked with rockspec_version properly. Cheers, -- Hisham ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk _______________________________________________ Luarocks-developers mailing list Luarocks-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/luarocks-developers
