[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: non-input dependencies Was: guile-dbi from guix not working

From: Zelphir Kaltstahl
Subject: Re: non-input dependencies Was: guile-dbi from guix not working
Date: Sun, 29 May 2022 14:42:32 +0000


On 5/29/22 10:58, raingloom wrote:
On Sun, 29 May 2022 13:27:23 +0530
Arun Isaac <> wrote:

Hi Zelphir,

Should guile-dbd-sqlite3 not be a dependency of guile-dbi then? But
on the other hand, what if one only wanted to interact with one
database type and not the other? So maybe not a must have dependency
then. Hm. What is the typical Guix solution for this kind of
"specialization" of a library? I think in the Python world, in
requirements files it would be something like
`library[specialization] == version`, to install that variant.
You can think of guile-dbd-* as plugins for guile-dbi. So, you install
guile-dbi along with whatever plugins you want for guile-dbi. It's no
different from installing emacs and installing emacs packages of
interest. I don't think we need a special Guix feature for this.

But, guile-dbi should be fixed to produce a proper error message that
a required plugin is missing. It should not produce misleading error
messages like "file not found". If you're up for it, you can try
reporting this to guile-dbi upstream.


I disagree, Guix packages should make it clear when they have
non-input dependencies. Users should not be forced to play
Run-time dependencies should either be listed in the package
description or in some extra field.
I absolutely hate it that I have to go look at bug trackers and
external docs to find out why a package I installed isn't working
correctly, especially when other package managers have already solved
this issue.
We don't have to do the exact same thing as them, but there has to be
some way for a user to know if, for example, they need ffmpeg in their
manifest if they want to use yt-dlp.

I think I get both of your viewpoints. I did not think of the database specific packages as plugins, but it makes sense. However, it also makes sense, that you need at least one of them, to actually do anything with guile-dbi (as far as I know), so it is also not the case, that you could make much use of guile-dbi without any of those packages.

Maybe one solution could be having 1 general package acting like guile-dbi package is acting now, in terms of dependencies, and also having N packages, one for each guile-dbi + database specific combination, so that you can install a package that does take care of installing all things required for working with that specific database.

But maybe that would become too many packages in the future to keep track of and update accordingly. And also now I know what mistake I made and things work. But what about the next person? Is there some way, that there could be a hint, when installing guile-dbi, that you might need another package as well? And how often is there such a situation? Maybe creating a general solution is not worth it, or maybe it is.

Of course, the error message could be better, as it also directed me to tripple and quadruppel checking, that I am specifying the correct filename and that I am not insane.

Anyway, thanks for the help and the explanations all : )

Best regards,


reply via email to

[Prev in Thread] Current Thread [Next in Thread]