opam importer can't handle list field

  • Open
  • quality assurance status badge
Details
2 participants
  • Julien Lepiller
  • Csepp
Owner
unassigned
Submitted by
Csepp
Severity
normal
C
(name . Bug reports for GNU Guix)(address . bug-guix@gnu.org)
86h6wg652t.fsf@riseup.net
Truncated stack trace:

```
...
In guix/import/opam.scm:
287:2 3 (opam->guix-package "mirage-crypto-pk" #:repo _ # _)
In unknown file:
2 (filter #<procedure 7f43905afd00 at guix/import/opam.s…> …)
In guix/import/opam.scm:
290:13 1 (_ ("mirage-no-solo5" "mirage-no-xen"))
In unknown file:
0 (string-prefix? "conf-" ("mirage-no-solo5" "mirage-n…") …)

ERROR: In procedure string-prefix?:
In procedure string-prefix?: Wrong type argument in position 2 (expecting string): ("mirage-no-solo5" "mirage-no-xen")
```
J
J
Julien Lepiller wrote on 28 Jan 2023 13:18
(name . Csepp)(address . raingloom@riseup.net)(address . 61033@debbugs.gnu.org)
20230128131811.23b5806c@sybil.lepiller.eu
Le Tue, 24 Jan 2023 03:23:44 +0100,
Csepp <raingloom@riseup.net> a écrit :

Toggle quote (21 lines)
> Truncated stack trace:
>
> ```
> ...
> In guix/import/opam.scm:
> 287:2 3 (opam->guix-package "mirage-crypto-pk" #:repo _ # _)
> In unknown file:
> 2 (filter #<procedure 7f43905afd00 at guix/import/opam.s…>
> …) In guix/import/opam.scm:
> 290:13 1 (_ ("mirage-no-solo5" "mirage-no-xen"))
> In unknown file:
> 0 (string-prefix? "conf-" ("mirage-no-solo5" "mirage-n…")
> …)
>
> ERROR: In procedure string-prefix?:
> In procedure string-prefix?: Wrong type argument in position 2
> (expecting string): ("mirage-no-solo5" "mirage-no-xen") ```
>
>
>

The issue is related to lines like this in the list of dependencies:

(("mirage-no-solo5" & "mirage-no-xen") | "zarith-freestanding" |
"mirage-runtime" {>= "4.0"})

This reads as a choice between three dependencies:
- mirage-no-solo5 with mirage-no-xen
- zarith-freestanding
- mirage-runtime

The importer infrastructure is not intelligent enough to really be able
to solve constraints in imported packages, so I don't see an easy
solution. It could silently use the first option, or put a comment
instead.

Ideas?
C
(name . Julien Lepiller)(address . julien@lepiller.eu)
871qnebgex.fsf@riseup.net
Julien Lepiller <julien@lepiller.eu> writes:

Toggle quote (41 lines)
> Le Tue, 24 Jan 2023 03:23:44 +0100,
> Csepp <raingloom@riseup.net> a écrit :
>
>> Truncated stack trace:
>>
>> ```
>> ...
>> In guix/import/opam.scm:
>> 287:2 3 (opam->guix-package "mirage-crypto-pk" #:repo _ # _)
>> In unknown file:
>> 2 (filter #<procedure 7f43905afd00 at guix/import/opam.s…>
>> …) In guix/import/opam.scm:
>> 290:13 1 (_ ("mirage-no-solo5" "mirage-no-xen"))
>> In unknown file:
>> 0 (string-prefix? "conf-" ("mirage-no-solo5" "mirage-n…")
>> …)
>>
>> ERROR: In procedure string-prefix?:
>> In procedure string-prefix?: Wrong type argument in position 2
>> (expecting string): ("mirage-no-solo5" "mirage-no-xen") ```
>>
>>
>>
>
> The issue is related to lines like this in the list of dependencies:
>
> (("mirage-no-solo5" & "mirage-no-xen") | "zarith-freestanding" |
> "mirage-runtime" {>= "4.0"})
>
> This reads as a choice between three dependencies:
> - mirage-no-solo5 with mirage-no-xen
> - zarith-freestanding
> - mirage-runtime
>
> The importer infrastructure is not intelligent enough to really be able
> to solve constraints in imported packages, so I don't see an easy
> solution. It could silently use the first option, or put a comment
> instead.
>
> Ideas?

I think in unhandled cases it should emit something usable instead of
erroring, like how it can already emit missing-source or whatever symbol
it uses.

If Guile had good error types like, like Result in OCaml or Rust, it
could signal this with the Error variant and then the sexp it failed on
as a parameter.

Alternatively we could do what Nix does and have importers implemented
externally, so we could just hook into OPAM and let it run its solver
and then emit Guix package definitions. It already has a distro
integration system anyways.

So far these errors have been rare enough that handling them on a case
by case basis is acceptable, however I also ran into issues where the
wrong version of a package was imported and I spent hours trying to
debug the build until I realized I imported a version that's too new.
Having an opam2guix tool would solve that.
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 61033@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 61033
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch