v28 No matching versions for query "latest" #536

cousine · 2020-02-16T19:35:39Z

Hi,

I'm trying to import v28 into a fresh project but getting the following error when compiling:

go: finding gopkg.in/libgit2/git2go.v28 latest
git-meister imports
    gopkg.in/libgit2/git2go.v28: no matching versions for query "latest"

I have libgit2 v0.28.4-1 installed.

P.S. I had v27 installed and its working fine

The text was updated successfully, but these errors were encountered:

lhchavez · 2020-02-16T21:42:36Z

huh, i just tried it earlier today and worked fine :S #535 (comment)

what version of go are you using? there seems to be some problems with go 1.11-1.12 and modules per golang/go#27215

do you have any other ways of helping us reproduce the issue?

slyphon · 2020-02-18T04:01:00Z

I've been having this same issue:

$ mkdir /tmp/modules
$ cd /tmp/modules 
$  go mod init github.com/slyphon/git2go-missing-latest-v28
go: creating new go.mod: module github.com/slyphon/git2go-missing-latest-v28

$ go get gopkg.in/libgit2/git2go.v28
go: finding gopkg.in/libgit2/git2go.v28 latest
go get gopkg.in/libgit2/git2go.v28: no matching versions for query "upgrade"

$ go get -v  gopkg.in/libgit2/git2go.v28
get "gopkg.in/libgit2/git2go.v28": found meta tag get.metaImport{Prefix:"gopkg.in/libgit2/git2go.v28", VCS:"git", RepoRoot:"https://gopkg.in/libgit2/git2go.v28"} at //gopkg.in/libgit2/git2go.v28?go-get=1
go: finding gopkg.in/libgit2/git2go.v28 latest
go get gopkg.in/libgit2/git2go.v28: no matching versions for query "upgrade"

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/jsimms/Library/Caches/go-build"
GOENV="/Users/jsimms/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/jsimms/go/1.13.7"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/Users/jsimms/.goenv/versions/1.13.7"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/Users/jsimms/.goenv/versions/1.13.7/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/tmp/modules/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/j7/hv7fd5kx1mqdpsc9sdx263kh0000gn/T/go-build631746544=/tmp/go-build -gno-record-gcc-switches -fno-common"

$ cat go.mod
module github.com/slyphon/git2go-missing-latest-v28

go 1.13

$ cd /tmp
$ go get -v gopkg.in/libgit2/git2go.v28
gopkg.in/libgit2/git2go.v28
$ echo $?
0
$

The behavior is only present when in a directory with a go.mod file.

I'm too new to dealing with modules to know what to suggest, but I'd be happy to provide any more information that would be useful.

This is reproducible in a golang:alpine docker instance

$ docker pull golang:1.13-alpine3.11
$ docker run -it --rm golang:1.13-alpine3.11 /bin/sh

/go # apk update
fetch http://dl-cdn.alpinelinux.org/alpine/v3.11/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.11/community/x86_64/APKINDEX.tar.gz
v3.11.3-71-g8230b2bd71 [http://dl-cdn.alpinelinux.org/alpine/v3.11/main]
v3.11.3-60-gb3a10d424a [http://dl-cdn.alpinelinux.org/alpine/v3.11/community]
OK: 11263 distinct packages available

/go # apk add git bash
(1/10) Installing ncurses-terminfo-base (6.1_p20191130-r0)
(2/10) Installing ncurses-terminfo (6.1_p20191130-r0)
(3/10) Installing ncurses-libs (6.1_p20191130-r0)
(4/10) Installing readline (8.0.1-r0)
(5/10) Installing bash (5.0.11-r1)
Executing bash-5.0.11-r1.post-install
(6/10) Installing nghttp2-libs (1.40.0-r0)
(7/10) Installing libcurl (7.67.0-r0)
(8/10) Installing expat (2.2.9-r1)
(9/10) Installing pcre2 (10.34-r1)
(10/10) Installing git (2.24.1-r0)
Executing busybox-1.31.1-r9.trigger
OK: 31 MiB in 25 packages

/go # /bin/bash

bash-5.0# apk add libgit2
(1/3) Installing http-parser (2.9.2-r0)
(2/3) Installing libssh2 (1.9.0-r1)
(3/3) Installing libgit2 (0.28.4-r0)
OK: 32 MiB in 28 packages

bash-5.0# mkdir /tmp/module

bash-5.0# cd /tmp/module/

bash-5.0# go mod init github.com/slyphon/omgwtfbbq
go: creating new go.mod: module github.com/slyphon/omgwtfbbq

bash-5.0# go get -v gopkg.in/libgit2/git2go.v28
get "gopkg.in/libgit2/git2go.v28": found meta tag get.metaImport{Prefix:"gopkg.in/libgit2/git2go.v28", VCS:"git", RepoRoot:"https://gopkg.in/libgit2/git2go.v28"} at //gopkg.in/libgit2/git2go.v28?go-get=1
go: finding gopkg.in/libgit2/git2go.v28 latest
go get gopkg.in/libgit2/git2go.v28: no matching versions for query "upgrade"

bash-5.0# cat go.mod
module github.com/slyphon/omgwtfbbq

go 1.13

bash-5.0# go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/root/.cache/go-build"
GOENV="/root/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/tmp/module/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build151185040=/tmp/go-build -gno-record-gcc-switches"

slyphon · 2020-02-18T04:05:12Z

BTW, I tried to install this via go get -v github.com/libgit2/[email protected] (i.e. using the tag in the repository) but git_dynamic.go is still tagged at 0.27.

Is this correct for how the git2go project manages tagging and releases?

lhchavez · 2020-02-18T14:13:23Z

BTW, I tried to install this via go get -v github.com/libgit2/[email protected] (i.e. using the tag in the repository) but git_dynamic.go is still tagged at 0.27.

Is this correct for how the git2go project manages tagging and releases?

Just created v0.28.4.1, that one should work.

slyphon · 2020-02-18T20:53:32Z

BTW, I tried to install this via go get -v github.com/libgit2/[email protected] (i.e. using the tag in the repository) but git_dynamic.go is still tagged at 0.27.
Is this correct for how the git2go project manages tagging and releases?

Just created v0.28.4.1, that one should work.

Thank you! I didn't intend my comment to be snippy, I thought I didn't understand how this tracks libgit2. Very much appreciate this project and your efforts!

lhchavez · 2020-02-19T03:39:55Z

BTW, I tried to install this via go get -v github.com/libgit2/[email protected] (i.e. using the tag in the repository) but git_dynamic.go is still tagged at 0.27.
Is this correct for how the git2go project manages tagging and releases?

Just created v0.28.4.1, that one should work.

Thank you! I didn't intend my comment to be snippy, I thought I didn't understand how this tracks libgit2. Very much appreciate this project and your efforts!

oh now i read my reply and it comes as being a bit curt. it wasn't my intention ^^;;

so far this is what i've gathered:

to the best of my knowledge, go get -v github.com/libgit2/[email protected] works, since that is using the exact tag name and requires no further processing from the tools. but that is a bit cumbersome to use :S
now that the libgit2's v1 release is nearing, we may need to rename the git2go branches. otherwise the "latest" will be v28, which is going to point to v0.28.x instead of v1.x.y!
1. an alternative could be using v100 for v1.0.0 and v101 for v1.1.0
2. that also comes with downsides. if we ever need to bump the major version for go tooling purposes (say, we want to add an API breaking change), it'll make things a bit complicated.

let me ask around and see if there are any good options i'm missing.

This is compliant with https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher, which says ``` Major branch: Update the go.mod file to include a /v3 at the end of the module path in the module directive (e.g., module github.com/my/module/v3). Update import statements within the module to also use /v3 (e.g., import "github.com/my/module/v3/mypkg"). Tag the release with v3.0.0. ``` This also means that unfortunately we cannot keep using libgit2's exact version number (plus a build number for git2go purposes, since go only recognizes vMAJOR.MINOR.PATCH format). (Tentatively) fixes: libgit2#536

This is compliant with https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher, which says ``` Major branch: Update the go.mod file to include a /v3 at the end of the module path in the module directive (e.g., module github.com/my/module/v3). Update import statements within the module to also use /v3 (e.g., import "github.com/my/module/v3/mypkg"). Tag the release with v3.0.0. ``` This also means that unfortunately we cannot keep using libgit2's exact version number (plus a build number for git2go purposes, since go only recognizes vMAJOR.MINOR.PATCH format). (Tentatively) fixes: #536

lhchavez · 2020-02-21T03:36:47Z

after reading a bit more, i have a proposal.

given that we don't want to break every single person that has already started using git2go, the current branches will be kept in perpetuity.
new branches with the name pattern release-${LIBGIT_MAJOR_VERSION}.${LIBGIT_MINOR_VERSION} will be created. that way people can refer to these branches unambiguously from go get using go get -v github.com/libgit2/[email protected], since branches that start with v${number} are treated as semver and are completely ignored.
follow Go's requirements for supporting APIs within modules. This means that every time an API incompatibility is introduced OR a new libgit2 major/minor version is released, a new vXbranch will be created. The X will be independent of libgit2's version. Since we already have v27 and v28 branches, this will start in v29 for libgit2 0.99. that has the implication that if there is ever a minor release that introduces a breaking API change (from Go's perspective), that would warrant a git2go major version bump for that release AND for master.

this might make it a bit unwieldy to use with gopkg.in, but given that the tooling has improved in the last months, it might be okay in the end. if there are no major concerns, this will be implemented some time next week now that libgit2 0.99.0 has been released and we would need to create new branches anyways.

slyphon · 2020-02-21T18:20:15Z

FWIW this sounds good to me. I worked on bindings for ZK for a long time, and I know how difficult it is when you need to have two versions that you're representing with one name.

I'm generally of the opinion that releases should be tagged, that way there's an unambiguous pointer with human meaning given to a specific revision of the code. Repeatability is generally the primary concern that I have.

That being said, and in my (admittedly inexpert) reading of the go.mod docs regarding the role of go.sum I believe that repeatable builds are baked in through other means, so using a branch seems to be a fine approach. I like the idea of having the specific release-${MAJOR}-${MINOR} branches, and the v${semver} being separate concerns. The problem that led me here was that brew installs v28, but I couldn't get the matching git2go version to install, which was the beginning of something of a wild goose chase, as I'm not quite up to speed on the go packaging tooling. It sounds like having the release-${MAJOR}-${MINOR} branches would have worked well for me.

Again, thank you for your efforts, and for giving careful thought to this issue. I find this project immeasurably useful (especially since it means I don't have to go learn C++, which some others are strong advocates for). Cheers! :)

lhchavez · 2020-03-08T20:44:32Z

All right, all tags have been created and now gopkg.in is much happier.

v29 now points to libgit2 0.99.

This is compliant with https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher, which says ``` Major branch: Update the go.mod file to include a /v3 at the end of the module path in the module directive (e.g., module github.com/my/module/v3). Update import statements within the module to also use /v3 (e.g., import "github.com/my/module/v3/mypkg"). Tag the release with v3.0.0. ``` This also means that unfortunately we cannot keep using libgit2's exact version number (plus a build number for git2go purposes, since go only recognizes vMAJOR.MINOR.PATCH format). (Tentatively) fixes: libgit2#536

lhchavez mentioned this issue Feb 19, 2020

Add the /v28 suffix to go.mod #537

Merged

lhchavez mentioned this issue Mar 4, 2020

Uprev vendor/libgit2 to v0.99 #540

Merged

lhchavez closed this as completed Mar 8, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

v28 No matching versions for query "latest" #536

v28 No matching versions for query "latest" #536

cousine commented Feb 16, 2020

lhchavez commented Feb 16, 2020

slyphon commented Feb 18, 2020

slyphon commented Feb 18, 2020

lhchavez commented Feb 18, 2020

slyphon commented Feb 18, 2020

lhchavez commented Feb 19, 2020

lhchavez commented Feb 21, 2020

slyphon commented Feb 21, 2020

lhchavez commented Mar 8, 2020

v28 No matching versions for query "latest" #536

v28 No matching versions for query "latest" #536

Comments

cousine commented Feb 16, 2020

lhchavez commented Feb 16, 2020

slyphon commented Feb 18, 2020

slyphon commented Feb 18, 2020

lhchavez commented Feb 18, 2020

slyphon commented Feb 18, 2020

lhchavez commented Feb 19, 2020

lhchavez commented Feb 21, 2020

slyphon commented Feb 21, 2020

lhchavez commented Mar 8, 2020