On 2024-04-10 17:17:27 +0200, Ludovic Courtès wrote:
> Hello,
>
> Tomas Volf <~@wolfsden.cz> skribis:
>
> > After ~2 hours of digging I realized this is caused by the changes in
> > 883e69cdfd226c8f40b6e3b76ce0740b59857de6.
> >
> > I see couple of issues here (in no particular order, questions prefixed with Q):
> >
> > * My configuration file just *silently* stopped working.
> >
> > That is not great for obvious reasons.
> >
> > * There is no news entry
>
> Oops, my apologies; the change felt pretty innocuous when I merged it,
> but in hindsight, it seems clear that a news entry was warranted.
> Lesson learned.
>
> We can still add that news entry, though fewer people will see it now.
>
> Thoughts?

Sorry for the late response, I have sadly been somewhat busy.  I see, so even if
you add the news entry now, only people who had not yet pulled the commit in
question would see it.  If that is the case, there is probably not much of a
reason to do it now.

>
> > * Broken default behavior.
> >
> > Currently, out of the box, extra-special-file with "/etc/guix/channels.scm" just
> > does not do anything.  No error, no warning.  That is pretty unexpected.
>
> Yes, why is that?  At first sight, that’s because ‘extra-special-file’
> does things at activation time; there’s no check happening at
> configuration time.
>
> It was really meant for /bin/sh, /usr/bin/env, and similar.  The reason
> its effect is silently dismissed in this case is, I think, because its
> activation runs before the /etc activation.  So it’s really bad luck.
>
> I’m not sure what to do here, apart from maybe recommending against
> broad use of this service.

I will re-phrase the above into a documentation patch.

>
> > * There is no terse way to turn it off
> >
> > Currently my configuration contains this:
> >
> >       (modify-services %base-services
> >         (guix-service-type
> >          config => (guix-configuration
> >                     (inherit config)
> >                     (channels #f))))
>
> Hmm right.  You do want to create /etc/guix/channels.scm though, right?
> (Since you had it initially.)

Yes, I do want to create it, but with (channels #f) the (extra-special-file)
works again. ^_^

>
> > * Q: Is there an easy way to fill (channels)?
> >
> > After I learned that (channels) is a thing, I wanted to use it, but did not find
> > any simple way how to do so.  My channels are in channels.scm produced by `guix
> > describe --format=channels', and I do not see any simple way to pass the content
> > of that file into (channels).  No, it does not accept (local-file).  I tried
> > just (read)-ing it, but that too does not work.
>
> That would be: (guix-configuration … (channels (load "channels.scm"))).

That does not seems to work, I am getting this error:

    /tmp $ guix system build os.scm
    ;;; compiling /tmp/channels.scm
    ;;; /tmp/channels.scm:1:7: warning: possibly unbound variable `channel'
    ;;; /tmp/channels.scm:2:9: warning: possibly unbound variable `name'
    ;;; /tmp/channels.scm:3:9: warning: possibly unbound variable `url'
    ;;; /tmp/channels.scm:4:9: warning: possibly unbound variable `branch'
    ;;; /tmp/channels.scm:5:9: warning: possibly unbound variable `commit'
    ;;; /tmp/channels.scm:7:9: warning: possibly unbound variable `introduction'
    ;;; /tmp/channels.scm:8:11: warning: possibly unbound variable `make-channel-introduction'
    ;;; /tmp/channels.scm:10:13: warning: possibly unbound variable `openpgp-fingerprint'
    ;;; compiled /home/wolf/.cache/guile/ccache/3.0-LE-8-4.6/tmp/channels.scm.go
    Backtrace:
    In guix/scripts/system.scm:
       1306:4 19 (_)
    In ice-9/boot-9.scm:
      1752:10 18 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
    In guix/store.scm:
       661:37 17 (thunk)
       1300:8 16 (call-with-build-handler #<procedure 7f9cf8f76de0 at guix/ui.scm:1222:2 (con…> …)
      2180:25 15 (run-with-store #<store-connection 256.100 7f9cfc3f4370> _ #:guile-for-build _ …)
    In guix/scripts/system.scm:
        848:2 14 (_ _)
        722:8 13 (_ #<store-connection 256.100 7f9cfc3f4370>)
    In gnu/system.scm:
      1300:19 12 (operating-system-derivation _)
       837:11 11 (operating-system-services #<<operating-system> kernel: #<package linux-libre…>)
    In /tmp/os.scm:
        19:12 10 (services #<<operating-system> kernel: #<package linux-libre@6.8.5 gnu/packag…>)
    In gnu/services.scm:
       383:23  9 (%modify-services (#<<service> type: #<service-type login 7f9cfbd70840> v…> …) …)
    In srfi/srfi-1.scm:
       460:18  8 (fold #<procedure 7f9cfc0759e0 at gnu/services.scm:383:29 (service services)> …)
    In gnu/services.scm:
       384:37  7 (_ #<<service> type: #<service-type guix 7f9cfbd92240> value: #<<guix-config…> …)
       354:28  6 (apply-clauses _ #<<service> type: #<service-type guix 7f9cfbd92240> value: …> …)
    In /tmp/os.scm:
        23:36  5 (_ #<<service> type: #<service-type guix 7f9cfbd92240> value: #<<guix-configu…>)
    In ice-9/boot-9.scm:
       2836:4  4 (save-module-excursion #<procedure 7f9cf8536cf0 at ice-9/boot-9.scm:4393:3 ()>)
      4388:12  3 (_)
    In /tmp/channels.scm:
          1:7  2 (_)
    In ice-9/boot-9.scm:
      1685:16  1 (raise-exception _ #:continuable? _)
      1685:16  0 (raise-exception _ #:continuable? _)

    ice-9/boot-9.scm:1685:16: In procedure raise-exception:
    error: channel: unbound variable

But after some experimentation (and looking into pull.scm), it seems what I need
is this:

    (use-modules (guix ui))
    (use-modules (guix channels))

and

    (channels (load* "channels.scm"
                     (make-user-module '((guix channels)))))

Which, while not exactly obvious, does work.

Maybe it would be best to extract (load-channels) from pull.scm into
guix/channels.scm, exporting it?  (Since for example the above is missing error
checking code from (load-channels)).

>
> > * Q: Is the default value right?
> >
> > Currently it defaults to %default-channels, which causes all this magic.  Would
> > it not be better to default to #f, so that it would do nothing magical out of
> > the box and would be backwards compatible?  You could still turn it on by
> > (Somehow?  See above.) providing desired value.
>
> Yes, we could change the default to #f: it’s equivalent to
> ‘%default-channels’ but wouldn’t cause the undesirable side effect you
> experienced.
>
> Do you want to prepare a patch (or two)? :-)

I will try to get to it over the weekend.

>
> Thanks for your feedback, and apologies again for the inconvenience!

No worries, these things happen ^_^

>
> Ludo’.
>

Tomas

--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.