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
