Hello,
Nguyễn Gia Phong <[email protected]> skribis:
>> To be clear, are you proposing a syntax for existing package
>> transformations? (Presumably ‘--with-input’ in the case above.)
>
> I was thinking about querying, so packages still have
> to be manually defined. What's proposed here only tries
> to make the specification more structural, e.g. lua-lgi?lua=5.4
> vs lua-lgi-lua-5.4 (or the actual status quo of lua5.4-lgi).
>
> --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.
Hmm, I’m not sufficiently familiar with Lua to understand this
particular example I guess.
What I can tell is that for HPC, where people like to fiddle with
package variants, we’ve used a mixture of two strategies:
• naming conventions to indicate package variants (some packages in
Guix have a ‘-openmpi’ variant, for instance);
• use of package transformations to create package variants.
I never thought of this third approach you’re suggesting (a query
language); my intuition and my desire for keeping things simple have me
feel like the two options above “should be enough for everyone”, to
paraphrase a famous software engineer.
WDYT?
>> You might have heard of previous proposals on “parameterized packages”,
>> which may be relevant:
>>
>> https://lists.gnu.org/archive/html/guix-devel/2020-11/msg00312.html
>> https://guix.gnu.org/en/blog/2023/parameterized-packages-for-gnu-guix/
>
> I haven't heard of it, what was its outcome?
The GSoC work was nice in many ways; it explored parameterization very
thoroughly. The downside in my view is that it was maybe too
sophisticated and, if used extensively, would immediately lead to
combinatorial explosion.
To me, it’s important for Guix packages to be well-tested. If we were
to advertise package parameterization as it was implemented, people may
often find themselves trying out a unique combination that no build farm
has ever tried before, and that’s really a terrible user experience.
(Package transformations also lead to unique configurations but they
have a clear “warranty void if used” sticker on it.)
>> combinatorial explosion
>
> On the other hand, what I wanted to discuss on
> is about concretely defined packages. The ultimate goal
> is the consistency of package-name, i.e. keeping the package's
> original name while it can still be referred to.
> To name more examples, 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-for-$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.
WDYT?
Ludo’.
