by having a config-5.1.lua in etc/config/ with correct variable to point to luajit binary / lib i can use luarocks --lua-version 5.1 to make it manage my luajit config
now i only need to make a wrapper to set the correct LUA_PATH / LUA_CPATH when using luajit
lol
main function has more than 120 local variables
@Nepta you can use the flag
--lua-version 5.x, or luarocks --local config lua_version 5.x to set the default permanently
but, to be honnest i did have some issue because i use luavela instead of the standard luajit
and it seem that luarocks have the names hardcoded when looking for the binary (either lua5.1 or luajit)
for now, i adding table.insert(names, "luavela) in util.lua work for me, but i am not familiar enough with luarocks config file, is there a way to add it in config-5.1.lua in some way ? it seem to have a field for it (lua_interpreter)
no, but there is a cpp backend available in luarocks.org which you can specify using build_dependencies!
i just saw that you are an admin on luarocks
thanks for your responses
Hi, I just noticed that the lpack rock, managed by Luarocks, is indicated as compatible with Lua 5.1, but it doesn't actually compile because it uses a Lua 5.0 type name,
luaL_reg (changed to luaL_Reg in Lua 5.1 when it was added to the manual). It must be based on the 5.0 version from LHF's site. Could it be fixed or at least marked as Lua 5.0 only?
Maybe not worth fixing because it's not maintained anymore (and was published with separate source code for each Lua version).
hi, si I am looking into luarocks to handle vim plugin management: as of neovim 0.5, there are many lua plugins and they still require everyone to manually setup the plugin dependencies in their init.lua. My hope is that we can use the rockspec format to communicate the dependencies and eventually use luarocks to disseminate these plugins. I wonder if this could be a problem to the luarocks infra/organization ? if not is there any recommendation as to how to handle that ? It's potentially a lot of new packages. Should we use a "neovim" manifest to help with discoveribility for instance ?
@teto this should not be a problem from the luarocks side, other projects use luarocks infra for managing plugins (Kong, Mjolnir). As for discoverability, I don't personally think a separate manifest is needed. mjolnir just used the "mjolnir" label, whereas kong uses a kong-plugin-foo naming convention.
seems like labels are not loaded automatically, at least when I go to https://luarocks.org/edit/modules/teto/plenary.nvim I dont see any "neovim" label even though the rockspec specifies it
how can I search by label ?
btw I maintain an out-of-tree luarocks additional command
luarocks nix and I would like to "find" a file (a .rockspec) in a folder. I can't find any luarocks function for that. Should I just os.execute and parse the result ?
I am facing this issue while installing busted
Step 8/14 : RUN luarocks install busted
---> Running in 598794b4c914
Warning: The directory '/root/.cache/luarocks' or its parent directory is not owned by the current user and the cache has been disabled. Please check the permissions and owner of that directory. If executing /usr/local/bin/luarocks with sudo, you may want sudo's -H flag.
Warning: Failed searching manifest: Failed fetching manifest for https://luarocks.org - Failed downloading https://luarocks.org/manifest - /tmp/luarocks_local_cache-IAhOjH/https___luarocks.org/manifest
Warning: Failed searching manifest: Failed fetching manifest for https://raw.githubusercontent.com/rocks-moonscript-org/moonrocks-mirror/master/ - Failed downloading https://raw.githubusercontent.com/rocks-moonscript-org/moonrocks-mirror/master/manifest - /tmp/luarocks_local_cache-IAhOjH/https___raw.githubusercontent.com_rocks-moonscript-org_moonrocks-mirror_master_/manifest
Installing http://luafr.org/moonrocks/busted-2.0.0-1.rockspec
Error: Could not satisfy dependency lua_cliargs == 3.0: No results matching query were found.
Missing dependencies for busted 2.0.0-1:
lua_cliargs == 3.0 (not installed)
luasystem >= 0.2.0 (not installed)
dkjson >= 2.1.0 (not installed)
say >= 1.3 (not installed)
luassert >= 1.8.0 (not installed)
lua-term >= 0.1 (not installed)
mediator_lua >= 1.1.1 (not installed)
busted 2.0.0-1 depends on lua_cliargs == 3.0 (not installed)
tried
sudo rm -rf ~/.luarocks but doesn't solve the issue
would you accept any PRs addressing luacheck issues, formatting Github actions ? (like stylua or luaformatter). You can check https://github.com/neovim/nvim-lspconfig/pulls for examples
https://github.com/aiq/basexx/blob/7acfe920345df885ba89c6feb307990cfc40c614/dist/basexx-scm-0.rockspec#L12 is the
... used for the url something standard ? I dont see it listed at https://github.com/luarocks/luarocks/wiki/Rockspec-format
it is not, that is a mistake in the rockspec (or it is a template for generating other rockspecs? I'm not familiar with that project)
re PRs for luacheck reports, I do not consider absolutely everything that luacheck reports to be an issue. We have a style guide repo in the luarocks org which I try to follow
I'd like to include it as a git submodule checked out to a specific version
hey hisham i got a question regarding luarocks's init command. It looks like the lua script that it comes with it's not picking up
lua_modules? I'm running lua 5.3 and luarocks 3.7.0. thanks
#!/bin/sh
LUAROCKS_SYSCONFDIR='/usr/local/etc/luarocks' exec '/usr/bin/lua5.3' -e 'package.path="/home/mrtn/.luarocks/share/lua/5.3/?.lua;/home/mrtn/.luarocks/share/lua/5.3/?/init.lua;/usr/local/share/lua/5.3/?.lua;/usr/local/share/lua/5.3/?/init.lua;"..package.path;package.cpath="/home/mrtn/.luarocks/lib/lua/5.3/?.so;/usr/local/lib/lua/5.3/?.so;"..package.cpath' $([ "$*" ] || echo -i) "$@"
perhaps this may be useful, @alerque :
I don't think it publishes rocks, but once luarocks is setup in the environment it may be a matter of running
luarocks upload (and maybe luarocks new_version to generate a new rockspec?) and storing your API key as an environment secret
I have next to no experience with Github Actions but I've seen similar things done with Travis CI in the past