libgit2/git2go

git2go@v0.28.4/git_dynamic.go:10:3: error: #error "Invalid libgit2 version; this git2go supports libgit2 v0.27"

spolischook opened this issue · 4 comments

spolischook commented

I'm using the latest Ubuntu LTS:

➜ lsb_release -a                                                                                                                     
LSB Version:	core-11.1.0ubuntu2-noarch:printing-11.1.0ubuntu2-noarch:security-11.1.0ubuntu2-noarch
Distributor ID:	Ubuntu
Description:	Ubuntu 20.04.2 LTS
Release:	20.04
Codename:	focal

In apt I found only dev and 28 version:

➜  sudo apt search libgit2
...
libgit2-28/focal,now 0.28.4+dfsg.1-2 amd64 [installed,auto-removable]
  low-level Git library

libgit2-dev/focal 0.28.4+dfsg.1-2 amd64
  low-level Git library (development files)
...

After install libgit2 from repositories I've got:

➜  lite git:(init-go-mod) go run main.go              
# github.com/libgit2/git2go
../../pkg/mod/github.com/libgit2/git2go@v0.28.4/git_dynamic.go:10:3: error: #error "Invalid libgit2 version; this git2go supports libgit2 v0.27"
   10 | # error "Invalid libgit2 version; this git2go supports libgit2 v0.27"
      |   ^~~~~

While in Readme, and it's reasonable, I see that v0.28.4 should support exactly 28 version of libgit2

lhchavez commented

ah! you need version v28, not v0.28. there was a little bit of confusion before we started doing legit go versioning ^^;;

  • 👍3
spolischook commented

What if developers has distinct versions of libgit2?
How we can have single codebase for different versions of lib?
splitsh had no go.mod before, and I start thinking that it was a right approach, as library was not tied with concrete implementation.

lhchavez commented

What if developers has distinct versions of libgit2?

The underlying libraries are not compatible with each other, and they have incompatible changes from Go's perspective, so we need to have different versions to comply with the new Go versioning semantics.

How we can have single codebase for different versions of lib?

That's not possible at the moment :( One thing I'd like to experiment at some point in the future is to have a lot of #ifdefs with compatibility logic to try to have a single git2go codebase that is able to link with a wide variety of libgit2 libraries. There are several edge cases with slight semantic implications that need a bit more thought, but if that is possible, then we may have a future where this is possible!

splitsh had no go.mod before, and I start thinking that it was a right approach, as library was not tied with concrete implementation.

The genie is now out of the bottle. The more the Go ecosystem as a whole moves to modules, the more pressure for libraries to have go.mod.

  • 👍2
spolischook commented

@lhchavez thanks for so detailed explanation. I appreciate your contribution in Go ecosystem.

  • 👍1