Simon Tournier <[email protected]> writes:
> Hi, > > On dim., 15 janv. 2023 at 12:12, Csepp <[email protected]> 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/[email protected]> > > 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.
