Re: Help to workaround libgit2 fetch refs issue

[Liliana Marie Prikler <liliana.prikler@gmail.com>]

Hi Phil,

Am Mittwoch, dem 02.03.2022 um 18:31 +0000 schrieb Phil:
> Hi Guixers,
> 
> I raised an issue on libgit2 which effects the use of Guix with SSH
> git clones and additional references:
> https://github.com/libgit2/libgit2/issues/6183
> 
> The issue in summary is that if I want to build off a non-standard
> git reference (say, a Pull Request), then even if I update my git
> config to include that, eg:
> remote.origin.fetch=+refs/pull-
> requests/*/merge:refs/remotes/origin/pr/*
> 
> libgit2's initial clone will not pull down the extra refs, despite
> this being the behaviour of the git command line tool proper.  After
> the initial clone, the git config is adhered to.
This portion of the bug is in libgit2 and thus is for libgit2 to care
about.

> In Guix this means that the first time I build a PR it fails, and I
> have to do something like "guix build  foo | guix build foo" which is
> at best a clumsy hack, but it works!
Note that you could alternatively just use the requesting repo URL in
the git-reference.  Ah, but that would be too boring, wouldn't it?

> Whilst the proper solution will be be done in libgit2 I was thinking
> if I could quickly improve on my double-build workaround without
> having to change Guix itself here (by always fetching):
> https://github.com/guix-mirror/guix/blob/6adce1538d2df6fa2d68abc13ae94e2fa826d124/guix/git.scm#L466
> 
> If nothing else I was hoping to learn a bit more about how packages
> were compiled as the details are a bit of blindspot for me!  So my
> plan was to duplicate the git-checkout record and it's G-Exp compiler
> such that I could redirect to a modified version of  update-cached-
> checkout when the source is read from the package.
> 
> (I should also mention that the far simpler option of providing a new
> "fetch" function like url-fetch or git-fetch doesn't work for me as
> the repo I'm accessing happens to require SSH authentication and thus
> I'm using the method as outlined here: 
> http://issues.guix.gnu.org/issue/31285#4 )
> 
> So I have something like:
>     (package
>       (name "my-test-repo")
>       (version production-version)
>       (source
>        (git-checkout-x-refs
>         (url "ssh://git@bitbucket:7999/ea/my-test-repo.git")
>         (commit commit-production)))
>       (build-system python-build-system)
>       and so on....
> 
> The code I've naively duplicated is at the bottom of this e-mail - it
> builds OK, so is syntactically correct, but fails when I reference it
> in a package like above.  Having the record and git code as part of
> my local channel is wrong, I know, but I'm looking a short term
> workaround with the least disruptive footprint whilst I implement and
> then wait for release of the strategic solution, probably in libgit2.
I don't think using a new record type is the way to go.  You only want
to change the behaviour of git-fetch into git-fetch/additional-refs.

> I suspect the reason for the failure is that I'd have to import my
> new duplicated module somewhere in the Guix core code to make this
> work - i.e. having the code in the channel is never going to work?
> 
> I was wondering if anyway could confirm this and/or give me a pointer
> of where the compliation occurs (where the record in the source is
> handled and compiled into a git clone) - even if my approach is
> (quite possibly) unviable, I'd like to understand why!
The source field of a package is not thunked, so it is compiled in the
package definition itself, rather than handed off.  Note that every
hack of doing something fancyful usually invokes at least a delay form,
see e.g. the computed-origin-method used by linux-libre.  Hope that
helps.

Cheers