Hi Ryan! As you've already seen, I've raised a PR with an attempt to fix some of the issues you ran into[1]. Once we confirm it actually works hopefully we can merge it and fix some of your issues.
One of the disappointments that you mention is one that I particularly feel: luarocks doesn't use the same lua as what "lua" on the CLI gives you. This is an unfortunate consequence of the way that Guix resolves names on the CLI: it finds all the packages with the same name, and it takes the highest version number. However, in Scheme code the "lua" variable points to [email protected], despite us having [email protected] packaged. In general in Guix we seem to use the bare Scheme name for the "default" version of something (e.g. the bare Ruby scheme variable is defined as ruby-3.3, despite ruby-3.4 and ruby-4.0 also being packaged). These bare names are often used in other packages throughout Guix. I have two thoughts about how to resolve this: 1. We could make sure that the "lua" variable always points to the most recent Lua version. This would mean that the versions would match by default (with Lua 5.5 at the moment), but you could still use [email protected] with lua5.4-luarocks and have things work out. In this case we would then want to use versioned names then declaring dependencies elsewhere in Guix, so things don't break when a new major version of lua is packaged. 2. We could define a new Guix feature to resolve names on the CLI to something other than the most recent version. This might work better for times when we would like to have a "default" version that isn't the latest, for some reason (like avoiding having to rebuild all dependent packages). Doing 1 would be within the scope of the Lua team, but I think this is a more general problem (as seen in Ruby, and possibly others) which might benefit from a more general solution. Carlo [1]: https://codeberg.org/guix/guix/pulls/9673
