unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
* bug#61033: opam importer can't handle list field
@ 2023-01-24  2:23 Csepp
  2023-01-28 12:18 ` Julien Lepiller
  0 siblings, 1 reply; 3+ messages in thread
From: Csepp @ 2023-01-24  2:23 UTC (permalink / raw)
  To: 61033

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")
```




^ permalink raw reply	[flat|nested] 3+ messages in thread

* bug#61033: opam importer can't handle list field
  2023-01-24  2:23 bug#61033: opam importer can't handle list field Csepp
@ 2023-01-28 12:18 ` Julien Lepiller
  2023-01-28 19:30   ` Csepp
  0 siblings, 1 reply; 3+ messages in thread
From: Julien Lepiller @ 2023-01-28 12:18 UTC (permalink / raw)
  To: Csepp; +Cc: 61033

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?




^ permalink raw reply	[flat|nested] 3+ messages in thread

* bug#61033: opam importer can't handle list field
  2023-01-28 12:18 ` Julien Lepiller
@ 2023-01-28 19:30   ` Csepp
  0 siblings, 0 replies; 3+ messages in thread
From: Csepp @ 2023-01-28 19:30 UTC (permalink / raw)
  To: Julien Lepiller; +Cc: 61033, Csepp


Julien Lepiller <julien@lepiller.eu> writes:

> 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.




^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2023-01-28 19:37 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-01-24  2:23 bug#61033: opam importer can't handle list field Csepp
2023-01-28 12:18 ` Julien Lepiller
2023-01-28 19:30   ` Csepp

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).