Julien Lepiller writes:
> Le Tue, 24 Jan 2023 03:23:44 +0100,
> Csepp 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 #
>> …) 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.
