Hi Phong, Thanks for starting this thread. I've definitely been finding myself thinking about this problem as I try to work out what a sensible Lua packaging scheme is.
I'm not yet convinced by your solution, though. On Mon, Mar 30 2026, Nguyễn Gia Phong wrote: > guix shell [email protected] lua-{lgi,penlight}?lua=5.4 Looking at this example, are you imagining that we would have multiple lua-lgi packages with the same version, but compatible with different lua versions? If that's the case, "guix shell lua lua-lgi" would be ambiguous - there are now multiple matching lua-lgi packages (with different properties). We either need to print warnings about the ambiguity, or we'd have to mark a default version somehow. I would actually prefer the opposite solution: remove the version part of specifications, and instead allow explicit aliases for packages. Thus, have lua-5.4 be an actual package name, and define lua as an alias to it for use in specifications. That way we always explicitly introduce package identifiers without the ambiguity of versions, and they can be discovered easily in the output of "guix show" and "guix search". The advantage of explicitly naming aliases is that we could choose to have "guix shell lua" use a lua package that isn't the latest version. (I'm currently considering this, as I want to package Lua 5.5, but doing so will break casual use of "guix shell lua lua-X" unless I update all the Lua libraries at the same time. Ditto for Ruby 4.) Explicitly providing aliases is also closer to the way we do things in Scheme, with things like "(define-public ruby ruby-3.3)". For the specific case of Lua, for many libraries we can build a single Guix package which supports all supported Lua versions. If we go with property filtering then we'll need to support packages holding a list of values against each property, and a query matching one of them. Carlo
