[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: libgit2 shallow clone (was Re: Packaging Grafana)
From: |
Csepp |
Subject: |
Re: libgit2 shallow clone (was Re: Packaging Grafana) |
Date: |
Mon, 16 Jan 2023 17:02:12 +0100 |
Simon Tournier <zimon.toutoune@gmail.com> writes:
> Hi,
>
> On dim., 15 janv. 2023 at 12:12, Csepp <raingloom@riseup.net> wrote:
>
>> Honestly, I think our Go importer needs to be rewritten to just use Go's
>> libraries instead of trying to replicate all functionality in Guile. It
>> does a lot of... let's say sub-optimal things currently, like cloning
>> full git repos, when Go is smart enough to only clone what it needs for
>> dependency resolution.
>
> About cloning, the core of the issue is not Guile but libgit2. Guix
> relies on guile-git which is just libgit2. And sadly, libgit2 does not
> support shallow clone or depth fetch option. See libgit2 issue#3058.
>
> If I read correctly, Go relies on plain Git, instead.
>
> Therefore, sadly we cannot do better than full Git repository clone.
>
> It would be difficult switch from libgit2 to plain Git; as discussed in
> this thread [2].
>
>
> 1: <https://github.com/libgit2/libgit2/issues/3058>
> 2: <https://yhetil.org/guix/87cz9fpw4x.fsf@gmail.com>
>
> Cheers,
> simon
It would be worth it for importers. If I remember correctly, the
reasoning for writing importers as Guile modules is reducing Guix's
closure size, but that's nonsense when it comes to importing packages,
because 99.9999% of the time you are going to be using the language's
tooling anyways, because you will want to actually compile those
imported packages.
The Rust importer already loads guile-json or whatever at runtime, there
is nothing wrong with having a similar runtime-only dependency on the Go
compiler.