Cannot use go get to include imgpkg libraries

[jpmcb]

What steps did you take:
In a new go project:

❯ go mod init example.com
go: creating new go.mod: module example.com

❯ go get github.com/vmware-tanzu/carvel-imgpkg
go get: github.com/vmware-tanzu/[email protected]: parsing go.mod:
	module declares its path as: github.com/k14s/imgpkg
	        but was required as: github.com/vmware-tanzu/carvel-imgpkg

I want to use the carvel libraries in a go project, but I am unable to use go get to pull in that dependency

What happened:
The go.mod should declare it's module as github.com/vmware-tanzu/carvel-imgpkg not github.com/k14s/imgpkg

What did you expect:
Be able to pull in the carvel libraries

Anything else you would like to add:
N/a

Environment:

Go 1.17 env:

GO111MODULE="on"
GOARCH="amd64"
GOBIN="/home/ubuntu/.asdf/installs/golang/1.17.2/go/bin"
GOCACHE="/home/ubuntu/.cache/go-build"
GOENV="/home/ubuntu/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/ubuntu/.asdf/installs/golang/1.17.2/packages/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/ubuntu/.asdf/installs/golang/1.17.2/packages"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/ubuntu/.asdf/installs/golang/1.17.2/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/ubuntu/.asdf/installs/golang/1.17.2/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.17.2"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/ubuntu/workspace/test-go/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 -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build2207886280=/tmp/go-build -gno-record-gcc-switches"

• imgpkg version (use imgpkg --version): N/a
• Docker registry used (e.g. Docker HUB): N/a
• OS (e.g. from /etc/os-release): N/a

---

Vote on this request

This is an invitation to the community to vote on issues, to help us prioritize our backlog. Use the "smiley face" up to the right of this comment to vote.

👍 "I would like to see this addressed as soon as possible"
👎 "There are other more important things to focus on right now"

We are also happy to receive and review Pull Requests if you want to help working on this issue.

[pivotaljohn]

Thank you, @jpmcb!

This is something that we've been tracking since our migration from the k14s org to the vmware-tanzu org: https://github.com/vmware-tanzu/carvel/issues/153

Two things for others coming across this issue:

1. one can go get with Carvel tools today by using the github.com/k14s.io/... module name. GitHub performs the needed redirect.
2. there are others who have integrated with some of the tools; included in this work is to give those folks some heads-up so they aren't suddenly broken when they grab the next release.

[pivotaljohn]

@DennisDenuto — do you have a sense of the best timing for completing the migration for imgpkg from k14s to vmware-tanzu?

[DennisDenuto]

Theres a few different perspectives.
tl;dr We should add some documentation and give a heads up. and then merge.

1. imgpkg shipped as a binary. Using a more 'accurate' module name shouldn't have any effect.
2. imgpkg consumed as a library. This would be a breaking change. However this is a distribution channel which we haven't officially supported and have stated to folk who are using it as a library that refactors with breaking API changes should be expected. Although we should be nice and give folk a heads up / document it appropriately as suggested in the linked issue. I don't see this affecting the timing.
3. carvel tools uniform module names: do we want to make this change in lock-step with the other tools? for folk using various carvel tools as a library it might be nice to bulk update them at the same time. However, I don't see this affecting the timing.

[pivotaljohn]

carvel tools uniform module names: do we want to make this change in lock-step with the other tools?

I don't see anything from where I'm sitting that would require these repos/modules needing to move in lock-step.

Would be nice just to put this behind us. :)

FWIW, GitHub redirects are indefinite: so long as a same-named repo is not created in the originating org, the redirect will continue to work.