`guix import go` fails outside of pre-inst-env

Hi,

As of commit ec8c7370dfd66136f7cb517d31fa6fda31e2cb74, the following `guix import` invocation fails:

$ guix import go --recursive github.com/tdewolff/minify/v2

Backtrace:

In ice-9/boot-9.scm:

222:29 19 (map1 _)

222:29 18 (map1 _)

222:29 17 (map1 _)

222:29 16 (map1 _)

222:29 15 (map1 _)

222:29 14 (map1 _)

222:29 13 (map1 _)

222:29 12 (map1 _)

222:29 11 (map1 _)

222:17 10 (map1 (((gnu packages check)) ((gnu packages #)) ((…)) …))

3327:17 9 (resolve-interface (gnu packages check) #:select _ # _ # …)

In ice-9/threads.scm:

390:8 8 (_ _)

In ice-9/boot-9.scm:

3253:13 7 (_)

In ice-9/threads.scm:

390:8 6 (_ _)

In ice-9/boot-9.scm:

3544:20 5 (_)

2836:4 4 (save-module-excursion _)

3564:26 3 (_)

In unknown file:

2 (primitive-load-path "gnu/packages/check" #<procedure a…>)

In gnu/packages/check.scm:

1037:13 1 (_)

In ice-9/boot-9.scm:

1685:16 0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:

error: go-github-com-robfig-cron: unbound variable

Strangely enough, it does work inside pre-inst-env with that same commit:

$ ./pre-inst-env guix import go --recursive github.com/tdewolff/minify/v2

(define-public go-github-com-djherbis-atime

<...>

I'm very unsure as to why this is happening, as `(gnu packages golang)` is imported in `(gnu packages check)`. Plus, even more weirdly, `guix build` can't find the problematic package, but can build the one that depends on it:

$ guix build go-github-com-robfig-cron-1.2

guix build: error: go-github-com-robfig-cron-1.2: unknown package

$ guix build actionlint

/gnu/store/0nzn1lbq02mfp6ka7z34lp9ly5nhlrv4-actionlint-1.6.23

I'd appreciate any help tracking down what could possibly be wrong here, as it's very puzzling.

Thanks,

Winter

Hi,

winter--- via Bug reports for GNU Guix <bug-guix@gnu.org> writes:

This is way worse: (gnu packages golang) cannot be loaded at all!

This is caused by a cycle, (gnu packages golang) uses (gnu packages

check) and vice-versa, and go-github-com-robfig-cron is defined in (gnu

packages golang)! So depending on whether you first use (gnu packages

check) or (gnu packages golang), go-github-com-robfig-cron will not have

been defined yet, hence the error.

Using (gnu packages check) then (gnu packages golang) doesn't make the

error appear. The solution imo, esp. since (gnu packages check) already

uses (gnu packages golang), is to have the variant package defined

alongside the parent. Here is a patch that should fix this.

Best,

--

Josselin Poiret

Becaus (gnu packages golang) and (gnu packages check) use each other, this

avoids an undefined symbol.

---

gnu/packages/check.scm | 18 ------------------

gnu/packages/golang.scm | 18 ++++++++++++++++++

2 files changed, 18 insertions(+), 18 deletions(-)

Hi,

On mer., 01 mars 2023 at 10:48, Josselin Poiret via Bug reports for GNU Guix <bug-guix@gnu.org> wrote:

-^

Typo

s/Becaus/Because I guess

Well, I have not given a look at this though. :-)

Cheers,

simon

Hi,

Great catch, thank you!

I still wonder what about pre-inst-env makes it so the order is different -- it's still the same code importing it, after all.

Also, just for posterity: I ran into a situation where I was only able to reproduce this from within a Guix shell, though that may be some oddities with regards to the shell caching symlinks in PATH(?)

I'll try to look into at least the latter issue, no clue what's up with pre-inst-env, though.

Thanks,

Winter

To clarify: I do think this is the best solution, though the oddities I mentioned may warrant further investigation into potentially different issues.

In addition to those, I wonder why `guix build` shows that the cyclic package can't be found, rather than throwing an error as `guix import` does. Maybe it's worth fixing that, if possible, to not cause (worse) confusion?

Thanks,

Winter

Hi again,

Winter <winter@winter.cafe> writes:

This is because you should be trying to build

`go-github-com-robfig-cron@1.2`, not `go-github-com-robfig-cron-1.2`!

`guix build` takes specifications, not Guile variable names.

Best,

--

Josselin Poiret

Op 02-03-2023 om 15:36 schreef Josselin Poiret:

I haven't gone to Guix days so I can't comment on that, but I'd like to

note that there are some simple patches for breaking up lots of package

cycles at https://issues.guix.gnu.org/54539#62 (*). In particular,

#:use-module -> #:autoload appears promising (^).

Basically, you can consider a module reference to be 'strong' if its of

the form (define stuff (package (inherit reference)) ...), and 'weak' if

its just a package input (or more generally, something thunked).

'Strong' cycles are problematic, but 'weak' cycles should be resolvable

by delaying loading the required modules until needed.

I don't know if these patches would solve this particular 'mate-polkit'

issue -- if the 'mate -> freedesktop -> ... -> xfce' cycle is 'weak',

something like those patches should work, but if it isn't, those patches

would be insufficient.

(*) Beware of https://issues.guix.gnu.org/54539#63though; looks like I

made some mistakes in hurd.scm and image.scm.

Greetings,

Maxime.

Hi Winter,

Simon Tournier ???

Pushed as 997b93cc4a6deff54ebd854a716cca94095114bf with this fix.

Thanks!

I'll close this bug now; the more general problem (and more

work-arounds to it) are tracked in others.

Kind regards,

T G-R