GNU bug report logs - #58112
OPAM importer fails in lookup-node

Previous Next

To reply to this bug, email your comments to 58112 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Csepp <raingloom <at> riseup.net>
To: Bug reports for GNU Guix <bug-guix <at> gnu.org>
Cc: julien <at> lepiller.eu
Subject: OPAM importer fails in lookup-node
Date: Tue, 27 Sep 2022 13:33:56 +0200

The specific error is this:
Wrong number of values returned to continuation (expected 2)
It is caused by opam->guix-package silencing intermediate errors by
using and-let* (the poor person's Maybe monad) and returning #f when the
receiving side expects two return values.

Initial reproducer:
guix import opam -r mirage

Also happens with opam-monorepo.

Cc-ing Julien whom might know why the code is structured this way?  It's
not like the calling side can handle a falsy return and the error is not
detected early either, so the user doesn't even know what is causing it.
Can I just turn it all into errors?  Or maybe we can use the condition
system?

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Julien Lepiller <julien <at> lepiller.eu>
To: Csepp <raingloom <at> riseup.net>, Bug reports for GNU Guix <bug-guix <at> gnu.org>
Subject: Re: OPAM importer fails in lookup-node
Date: Tue, 27 Sep 2022 17:42:06 +0200

[Message part 1 (text/plain, inline)]

It's probably because other importers are structured that way. I'd be in favor of changing that and using the condition system.

Le 27 septembre 2022 13:33:56 GMT+02:00, Csepp <raingloom <at> riseup.net> a écrit :
>The specific error is this:
>Wrong number of values returned to continuation (expected 2)
>It is caused by opam->guix-package silencing intermediate errors by
>using and-let* (the poor person's Maybe monad) and returning #f when the
>receiving side expects two return values.
>
>Initial reproducer:
>guix import opam -r mirage
>
>Also happens with opam-monorepo.
>
>Cc-ing Julien whom might know why the code is structured this way?  It's
>not like the calling side can handle a falsy return and the error is not
>detected early either, so the user doesn't even know what is causing it.
>Can I just turn it all into errors?  Or maybe we can use the condition
>system?
>

[Message part 2 (text/html, inline)]

Message #11 received at 58112 <at> debbugs.gnu.org (full text, mbox):

From: zimoun <zimon.toutoune <at> gmail.com>
To: Csepp <raingloom <at> riseup.net>, 58112 <at> debbugs.gnu.org
Cc: julien <at> lepiller.eu
Subject: Re: bug#58112: OPAM importer fails in lookup-node
Date: Tue, 27 Sep 2022 15:47:57 +0200

Hi,

On Tue, 27 Sep 2022 at 13:33, Csepp <raingloom <at> riseup.net> wrote:
> The specific error is this:
> Wrong number of values returned to continuation (expected 2)
> It is caused by opam->guix-package silencing intermediate errors by
> using and-let* (the poor person's Maybe monad) and returning #f when the
> receiving side expects two return values.
>
> Initial reproducer:
> guix import opam -r mirage

I have not checked for opam, but it reminds me fixes in other importers.

5278cab3dc * scripts: import: gem: Fix recursive error handling.
7229b0e858 * import: cran: Return multiple values for unknown packages.
1fe81b349c * import: elpa: Return multiple values for unknown packages.
6bb92098b4 * import: hackage: Return multiple values for unknown packages.

And the bug#44115 report [1] mentioned opam but indeed the fix probably
fell in the crack. :-)

Do you want to give a try?

1: https://issues.guix.gnu.org/44115




Cheers,
simon

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.