On Sun, 29 May 2022 14:42:32 +0000 Zelphir Kaltstahl <zelphirkaltst...@posteo.de> wrote:
> Hi! > > On 5/29/22 10:58, raingloom wrote: > > 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. > > 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, > Zelphir > IMHO as a first step we should just add this information to the package descriptions. Simple, backwards compatible, doesn't restrict us, etc. Eg.: for emacs-geiser, just add a line that says: "To use it with a given Scheme dialect, install emacs-geiser-<scheme-dialect> in the same environment." Bam, no more confusion over why a package isn't doing anything.
