Hi, On 2026-03-30 at 22:15+11:00, Carlo Zancanaro wrote: > On Mon, Mar 30 2026, Nguyễn Gia Phong wrote: > > guix shell [email protected] lua-{lgi,penlight}?lua=5.4 > > "guix shell lua lua-lgi" would be ambiguous - there are now > multiple matching lua-lgi packages (with different properties). > > 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.
Seconded, I am tired of the variable foo and specification "foo" referring to different packages TBH. On 2026-03-30 at 22:15+11:00, Carlo Zancanaro wrote: > 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. There's a slight complication with purely syntactic namespace: the package-name used in specifications needs to be substituted for each namespace. Since joining string is always easier than splitting them, perhaps there should be properties for the namespace and the denamespaced package name. On 2026-03-30 at 19:00+02:00, Ludovic Courtès wrote: > On 2026-03-30 at 18:01+09:00, Nguyễn Gia Phong wrote: > > we currently have: > > > > - lua$LUA_VERSION-$NAME > > - qt$NAME-$QT_VERSION > > - qt$QT_VERSION$NAME > > - zig-$NAME-for-zig-$ZIG_VERSION > > - $NAME-for-$DEPENDENT > > - $NAME-with-$FEATURE > > - $NAME-next > > > > In each of these name templete, it's guessing work > > to determine what the package-name actually is. > > > > Since we already have specification syntax for package-version, > > I wonder how bad of an idea could it be for a syntax > > for other variant-y properties. > > I'm generally wary of "stringy DSLs" like the spec syntax you're > proposing. In this case, I'd very much favor either a low-tech, > hand-crafted naming convention, or plain `--with-input'. > > What works best depends on the application domain, use cases, and > intended audience. It is not particularly clear to me what stringy DSL means as I thought all languages are to accept strings, but anyway my goal is more about making the metadata queriable for transformation. Another example of joining strings making this difficult is the name as name-version in build systems. There are de facto DSLs for these concatinated names, with functions to parse and unparse them even, and I think they introduce unnecessary complexities. Like natural languages, they look natural but are tricky to work with. I'll take some time to think about the relevant use cases to discuss the specification interface. In the mean time, I'd like to reach some common understanding on these for/with/next thingies. On 2026-03-30 at 10:18+02:00, Simon Tournier wrote: > That’s said, from my understanding, you are proposing a short for: > > guix shell [email protected] lua-{lgi,penlight} [email protected] I missed this in my other response so I'm quoting it here. On 2026-03-30 at 18:01+09:00, Nguyễn Gia Phong wrote: > --with-input is not sufficient because there could be anywhere > from 0 (e.g. no test) to >1 different "lua" packages in the (native) > input list. An example for the latter case would be using Lua 5.3 > for lua-ldoc while the package is for LuaJIT/Lua 5.1 API. On 2026-03-30 at 12:44+02:00, Sergio Pastor Pérez wrote: > As others pointed out, the parameterized packages effort has some > complexities, just for reference. We also have this Zulip conversation > where some of the previous discussions were listed. > > https://guix.zulipchat.com/#narrow/channel/564622-general/topic/parameterized.20packages.3F Thanks! Best wishes, Phong
signature.asc
Description: PGP signature
