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