From: raingloom <raingloom@riseup.net>
To: Zelphir Kaltstahl <zelphirkaltstahl@posteo.de>
Cc: Arun Isaac <arunisaac@systemreboot.net>, help-guix <help-guix@gnu.org>
Subject: Re: non-input dependencies Was: guile-dbi from guix not working
Date: Sun, 29 May 2022 17:23:14 +0200 [thread overview]
Message-ID: <20220529172314.5fabbe36@riseup.net> (raw)
In-Reply-To: <47d4043c-bc48-cc10-31af-2d4a212e45b1@posteo.de>
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.
next prev parent reply other threads:[~2022-05-29 15:23 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-07 11:26 guile-dbi from guix not working Zelphir Kaltstahl
2022-05-07 18:44 ` Luis Felipe
2022-05-08 12:33 ` Zelphir Kaltstahl
2022-05-25 19:18 ` Arun Isaac
2022-05-28 16:37 ` Zelphir Kaltstahl
2022-05-29 7:57 ` Arun Isaac
2022-05-29 8:58 ` non-input dependencies Was: " raingloom
2022-05-29 14:42 ` Zelphir Kaltstahl
2022-05-29 15:23 ` raingloom [this message]
2022-05-30 6:31 ` Arun Isaac
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220529172314.5fabbe36@riseup.net \
--to=raingloom@riseup.net \
--cc=arunisaac@systemreboot.net \
--cc=help-guix@gnu.org \
--cc=zelphirkaltstahl@posteo.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.