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

[raingloom]

On Sun, 29 May 2022 14:42:32 +0000
Zelphir Kaltstahl <zelphirkaltstahl@posteo.de> wrote:

> Hi!
> 
> On 5/29/22 10:58, raingloom wrote:
> > 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.  
> 
> 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.