Subject: Re: [PATCH] download: Do not wrap TLS port on GnuTLS >= 3.7.7.

From: Maxime Devos <[email-masked]>
Date: Thu, 4 Aug 2022 21:37:44 +0200

On 02-08-2022 09:59, Ludovic Courtès wrote:
>>> +      (if (module-defined? (resolve-interface '(gnutls))
>>> +                           'set-session-record-port-close!) ;GnuTLS >= 3.7.7
>> resolve-module (and presumably also sets #:ensure #t by default, which
>> sometimes causes 'module not found' messages to be replaced by
>> 'unbound variable', which I don't think is useful behaviour, can
>> #:ensure be set to #false?
> This is unnecessary: see the ‘load-gnutls’ mechanism there.  The idiom
> above is already used in a couple of places.

I have looked at the 'load-gnutls' procedure, but I do not see how it 
avoids the issue I mentioned (*).

I have also seen this idiom (resolve-interface and friends with #:ensure 
#t) before, in other places, but that doesn't make the idiom correct -- 
in fact, _because_ I've seen the idiom elsewhere causing problems, I 
recommend avoiding the same mistake here (and preferably also 
eliminating it elsewhere).

More generally, the second sentence is a logical fallacy, a variant of 
"ad populum" -- the prevalency of a mistake does not make it correct and 
does not invalidate evidence of it being a mistake.

To be clear, I am not referring to the existence/absence of compilation 
errors when compiling the Guix package without gnutls in the build 
environment, but to the confusing _contents_ of the error message and 
the odd semantics of #:ensure #t, and not only at compilation time but 
also at runtime.

(*) The autoloading of gnutls in load-gnutls avoids compilation errors 
when gnutls is absent, but by the way it does it, it causes the module 
to be registered as 'it exists' even when it doesn't, so the information 
in the module system of Guix becomes incorrect.

Greetings,
Maxime.