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

[raingloom <raingloom@riseup.net>]

On Sun, 29 May 2022 13:27:23 +0530
Arun Isaac <arunisaac@systemreboot.net> 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.
> 
> Cheers!
> Arun
> 

I disagree, Guix packages should make it clear when they have
non-input dependencies. Users should not be forced to play
dependency-whack-a-mole.
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.