unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: Christopher Baines <mail@cbaines.net>
To: Simon Tournier <zimon.toutoune@gmail.com>
Cc: 67250@debbugs.gnu.org
Subject: bug#67250: builtin:git-download capability detection not working for the bordeaux build farm
Date: Sat, 18 May 2024 14:32:05 +0100	[thread overview]
Message-ID: <87jzjrb60a.fsf@cbaines.net> (raw)
In-Reply-To: <87msuy9dem.fsf@gmail.com> (Simon Tournier's message of "Tue, 28 Nov 2023 15:10:41 +0100")

[-- Attachment #1: Type: text/plain, Size: 2533 bytes --]

Simon Tournier <zimon.toutoune@gmail.com> writes:

> On Wed, 22 Nov 2023 at 11:19, Ludovic Courtès <ludo@gnu.org> wrote:
>
>> As in:
>>
>>   (open-connection
>>     #:assume-available-builtin-builders '("download"))
>
> Instead, why not check in ’git-fetch’?  Currently, the test is done
> against the local daemon, right?
>
> --8<---------------cut here---------------start------------->8---
> (define* (git-fetch ref hash-algo hash
>                     #:optional name
>                     #:key (system (%current-system))
>                     guile git)
>   "Return a fixed-output derivation that fetches REF, a <git-reference>
> object.  The output is expected to have recursive hash HASH of type
> HASH-ALGO (a symbol).  Use NAME as the file name, or a generic name if #f."
>   (mlet %store-monad ((builtins (built-in-builders*)))
>     (if (member "git-download" builtins)
>         (git-fetch/built-in ref hash-algo hash name
>                             #:system system)
>         (git-fetch/in-band ref hash-algo hash name
>                            #:system system
>                            #:guile guile
>                            #:git git))))
> --8<---------------cut here---------------end--------------->8---
>
> For example, why not a test as:
>
>     (if (and SOMETHING
>              (member "git-download" builtins))
>
> And this SOMETHING could be a global variable, as
> %assume-builtin-builder, set to true by default and turn to false with
> an environment variable, as GUIX_ASSUME_BUILTIN.

I can think of a couple of reasons not to do this via an environment
variable.

Having the logic in git-fetch via an environment variable would mean
that if other builtins are added, the code generating derivations using
them would also have to check the environment variable. Specifying the
builtin's that are available on a store connection would work
automatically in the case of new builtins being added..

There's also trade-offs in control when using environment variables, or
deciding when to take the value from an environment variable and switch
to passing the value around through arguments or other means. Consider
the case where you have a single process which has multiple store
connections open and it wants to specify different available builtin's
on particular store connections. This would become quite difficult when
using an environment variable, but work easily when specifying the
builtins available on the store connection.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]

  reply	other threads:[~2024-05-18 13:33 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-17 21:39 bug#67250: builtin:git-download capability detection not working for the bordeaux build farm Christopher Baines
2023-11-20  9:59 ` Simon Tournier
2023-11-20 10:29   ` Christopher Baines
2023-11-22 10:19 ` Ludovic Courtès
2023-11-28 14:10   ` Simon Tournier
2024-05-18 13:32     ` Christopher Baines [this message]
2023-11-28 16:54   ` Christopher Baines
2024-05-18 13:22     ` Christopher Baines

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87jzjrb60a.fsf@cbaines.net \
    --to=mail@cbaines.net \
    --cc=67250@debbugs.gnu.org \
    --cc=zimon.toutoune@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).