Inconsistent package versioning between GitHub and GoPkg (please help a Go newbie)

Straight copy from the GitHub issue I was going to submit

(Which later on I thought that this would have been a better place)

What version of Go are you using (go version)?

$ go version
go version go1.14.2 linux/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

Debian 10 Buster Stable, Intel® Pentium® G4600 (x86_amd64)

$ uname -a
Linux debian-homepc.bryanpedini.home 4.19.0-8-amd64 #1 SMP Debian 4.19.98-1+deb10u1 (2020-04-27) x86_64 GNU/Linux
go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/bryanpedini/.cache/go-build"
GOENV="/home/bryanpedini/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/bryanpedini/projects/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=""
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 -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build004077584=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Currently trying to implement some APIs on top of an Echo framework instance on my home development PC.
Go environment always worked perfectly (all tho I don’t code that much myself, I’m still at “standard library level”, so I never needed to use versioned packages before), but now it started making a bundled mess with the package versions.

A simple, trimmed down version of the code I’m trying to execute: (without ini config files and stuff)
https://play.golang.org/p/IfCwkwtZAew (and it doesn’t work)

The output from my PC:

$ go get -u gopkg.in/labstack/echo.v4

$ go run main.go register.go user.go
../../../gopkg.in/labstack/echo.v4/middleware/basic_auth.go:8:2: cannot find package "github.com/labstack/echo/v4" in any of:
/usr/local/go/src/github.com/labstack/echo/v4 (from $GOROOT)
/home/bryanpedini/projects/go/src/github.com/labstack/echo/v4 (from $GOPATH)

$ go get -u github.com/labstack/echo/v4
package github.com/labstack/echo/v4: cannot find package "github.com/labstack/echo/v4" in any of:
/usr/local/go/src/github.com/labstack/echo/v4 (from $GOROOT)
/home/bryanpedini/projects/go/src/github.com/labstack/echo/v4 (from $GOPATH)

$ go get -u github.com/labstack/echo

$ go run main.go register.go user.go
# command-line-arguments
./main.go:13:38: cannot use middleware.RemoveTrailingSlash() (type "github.com/labstack/echo".MiddlewareFunc) as type "gopkg.in/labstack/echo.v4".MiddlewareFunc in argument to e.Pre

A slightly modified version:
https://play.golang.org/p/1PhlgeDA32V (which goes on timeout, clear sign to me that the Echo server started)

And finally, the result of that same code on my computer (just changing the imports basically):

$ go run main.go register.go user.go
main.go:7:2: cannot find package "github.com/labstack/echo/v4" in any of:
/usr/local/go/src/github.com/labstack/echo/v4 (from $GOROOT)
/home/bryanpedini/projects/go/src/github.com/labstack/echo/v4 (from $GOPATH)
main.go:8:2: cannot find package "github.com/labstack/echo/v4/middleware" in any of:
/usr/local/go/src/github.com/labstack/echo/v4/middleware (from $GOROOT)
/home/bryanpedini/projects/go/src/github.com/labstack/echo/v4/middleware (from $GOPATH)

And on VSCode linter (Microsoft’s own extension for Go) I get the same “could not import github/labstack/echo/v4 (no package for import github/labstack/echo/v4)”…

And last but not least, let’s try without a version, shall we? Linter vs Compiler… FIGHT:
The linter goes first with an uppercat


And then the Echo microserver takes the linter KO, 'cause actually runs fine… like, WHAT?

What did you expect to see?

An easy to use versioning system called gopkg.in

What did you see instead?

A mess of something I can’t describe almost never working with hard to guess import paths that sometimes work, sometimes won’t (and a general lack of understanding of my issues by Google’s search function’s fault: what part of “I can import go packages from github but not from gopkg” you didn’t get stupid AI? just find my 2003 forum post, okay? cit. Wisdom of the Ancients)

End of GH issue copy

Is there anything more I should try / need to know before diving in, in getting some more headakes due to my (not/mis)understanding of how Go packages work?
Does anybody know like a guide or something easy to “get in the thinking system”? Because the language itself is pretty straight forward, very much Cpp-like and (for me) easy to start understanding and writing right away… but the technical scheme, man!! To place files in an “src” folder and then a directory with the name of the git platform and then your username and finally the project name, well, that was easy; but yooo boy if I ever understood a needle of what every tutorial I watched was saying about packages, their structure and their import schemes (now more than ever with the (almost) new introduction of package modules’ versioning)…

Thanks to everybody in advance, and sorry for the papirus (as said, it was a copypaste from the GitHub issue template and it’s very detailed).
Bryan.

Welcome to Go Forum :rocket: :fireworks:


Before answering question as a whole: when you perform the prototyping, are you developing inside a go module?

Edit: there should be a go.mod inside your project directory.

1 Like

Thanks for your welcome!

About your question tho: I don’t really know, I mean, I create a new folder in my $GOPATH with the specifications’ structure, I create a main.go and start coding right away.
I heard about this go.mod file, but actually never created one, nor learned how to use it yet.

Is that the “starting point” I should look at when beginning to create code that has dependencies?
Because I find it a little bit strange that the code works, but my VSCode linter gives me something like this…

Okay…

Now both the code and the linter work just fine, after some go mod init here and some go mod tidy there.
The thing I still don’t understand is why before generating the go.mod and go.sum files with go mod tidy, the same code imports (in this case github.com/labstack/echo/v4) gave me errors while without the version they worked; but now it works even with the version appended to it…
Like, what? I mean, if it is for the go.mod that instructs the go builder to pick this and that and work fine, sure, I’m happy; but I now I would like to understand why even the linter gave me some errors before and now everything is fine. I don’t really think that VSCode linters go into go mod files to see if everything is alright, so I don’t quite get this thing…

Well, everything is fine when everything works fine after all, am I right?

I have not spin a git repo to test it out personally so if everything is fine then my hypothesis is correct: you were using the legacy approach to develop Go package.

go.mod (go.sum is the a record keeping those dependencies checksum) is basically a version “recording” tool of your package like the Gemfile in Ruby. It was designed with multiple objectives:

  1. version control all your package’s dependencies (in your case, v4 echo).
  2. allows developer to develop outside of GOPATH.
  3. eliminate dependency management hell by switching from rolling strategy of GOPATH to point release strategy of Go Module.
  4. sort out 3rd party packages import (there are so many ways like vendor, godep, etc.) into 1 way import.

Those are the problems in the Go’s legacy development approach. That’s why after the go,mod initialization, there are a lot of crazy things sorted out under the hood for you already. This is the new and acceptable approach today for building a Go package (be in binary program or package).

You should read up and understand about go module to get your workspace up here before proceeding further: https://blog.golang.org/using-go-modules. There are strict rules abide to go module.

2 Likes

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.