Navigation Menu

Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

cmd/go: go mod verify replaces tags manually set in go.mod #27271

Closed
aanm opened this issue Aug 27, 2018 · 2 comments
Closed

cmd/go: go mod verify replaces tags manually set in go.mod #27271

aanm opened this issue Aug 27, 2018 · 2 comments
Labels
FrozenDueToAge modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Go1.12

Comments

@aanm
Copy link

aanm commented Aug 27, 2018

Please answer these questions before submitting your issue. Thanks!

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

go version go1.11 linux/amd64

Does this issue reproduce with the latest release?

Yes

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

GOARCH="amd64"
GOHOSTARCH="amd64"
GOHOSTOS="linux"

What did you do?

Create a main.go file with:

package main

import (
	"k8s.io/client-go/kubernetes"
)

func main() {
	kubernetes.New(nil)
}

Have the go.mod file written with the content

module aanm/tests

require (
	k8s.io/client-go kubernetes-1.11.2
)

run GO111MODULE=on go mod tidy

Verify the content of go.mod and notice k8s.io/client kubernetes-1.11.2 was not kept nor a reference to the tag manually set.

module aanm/tests

require (
	github.com/davecgh/go-spew v1.1.1 // indirect
	github.com/ghodss/yaml v1.0.0 // indirect
	github.com/gogo/protobuf v1.1.1 // indirect
	github.com/golang/glog v0.0.0-20160126235308-23def4e6c14b // indirect
	github.com/golang/protobuf v1.2.0 // indirect
	github.com/google/btree v0.0.0-20180813153112-4030bb1f1f0c // indirect
	github.com/google/gofuzz v0.0.0-20170612174753-24818f796faf // indirect
	github.com/googleapis/gnostic v0.2.0 // indirect
	github.com/gregjones/httpcache v0.0.0-20180305231024-9cad4c3443a7 // indirect
	github.com/json-iterator/go v1.1.5 // indirect
	github.com/modern-go/concurrent v0.0.0-20180306012644-bacd9c7ef1dd // indirect
	github.com/modern-go/reflect2 v1.0.1 // indirect
	github.com/peterbourgon/diskv v2.0.1+incompatible // indirect
	github.com/pmezard/go-difflib v1.0.0 // indirect
	github.com/spf13/pflag v1.0.2 // indirect
	github.com/stretchr/testify v1.2.2 // indirect
	golang.org/x/crypto v0.0.0-20180820150726-614d502a4dac // indirect
	golang.org/x/net v0.0.0-20180826012351-8a410e7b638d // indirect
	golang.org/x/sync v0.0.0-20180314180146-1d60e4601c6f // indirect
	golang.org/x/sys v0.0.0-20180824143301-4910a1d54f87 // indirect
	golang.org/x/text v0.3.0 // indirect
	golang.org/x/time v0.0.0-20180412165947-fbb02b2291d2 // indirect
	gopkg.in/inf.v0 v0.9.1 // indirect
	gopkg.in/yaml.v2 v2.2.1 // indirect
	k8s.io/api v0.0.0-20180827053216-6b5087e25236 // indirect
	k8s.io/apimachinery v0.0.0-20180823151430-017bf4f8f588 // indirect
	k8s.io/client-go v2.0.0-alpha.0.0.20180806134042-1f13a808da65+incompatible
)

What did you expect to see?

  1. The k8s.io/client-go to keep tag kubernetes-1.11.2

(nice to have but not important)
2. All the indirect dependencies are extremely verbose. If I care about them I would check go.sum, I don't see the point on filling up the require, which IMO should be kept by the developer, to be filled up with transient dependencies.
@thepudds
Copy link
Contributor

thepudds commented Aug 27, 2018 •
edited

In case this helps, a couple quick initial comments regarding "the kubernetes-1.11.2 tag is not kept", along with some pointers to some possibly related doc.

The VCS tag kubernetes-1.11.2 will not be interpreted a semver tag by the go tooling.

For a VCS tag to be interpreted as a semver tag by the go tooling, the tag must encode a semantic version in the form v(major).(minor).(patch), such as v0.1.0, v1.2.3, or v3.0.1. The leading v is required by the go tooling.

A non-semver tag used in a require directive or in go get will be interpreted as a "Module query".

In general, module queries that do not resolve to a semver tag will be recorded as pseudo-versions in the go.mod file.

The "Module-aware go get" and "Module queries" sections of the tip documentation have a bit more info on these topics...

@gopherbot please add label modules

@FiloSottile FiloSottile added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Aug 30, 2018
@FiloSottile FiloSottile added this to the Go1.12 milestone Aug 30, 2018
@bcmills
Copy link
Contributor

bcmills commented Sep 27, 2018

@thepudds has the correct diagnosis. kubernetes-1.11.2 is not a valid semantic version, so it gets replaced by one that is.

The closest we could get while sticking to semantic versions is #25898, so I'm closing this as a duplicate of that.

@bcmills bcmills closed this as completed Sep 27, 2018
@aanm aanm mentioned this issue Feb 25, 2019
Closed
mangelajo pushed a commit to mangelajo/submariner that referenced this issue Jul 1, 2019
@mangelajo
Update to go mod
58cfb45 
We use the -mod=vendor strategy for building, and we add a target
on Makefile called vendor.

Apparently go-mod expects semver (vX.Y.Z) naming for tags/branches, but
kubernetes-1.13.2 is not in that format so for k8s.io/xxx packages
it gets replaced to v0.0.0-commit id every time we run go mod,
see: golang/go#27271

Go automatically detects ginkgo/gomega usage, and adds it to the
go.mod file, resulting in vendoring those pkgs, which may
be ok if we want to provide a built version of the e2e binary
as kubefed will be doing soon.
mangelajo added a commit to mangelajo/submariner that referenced this issue Jul 1, 2019
@mangelajo
Update to go mod
02d2f80 
We use the -mod=vendor strategy for building, and we add a target
on Makefile called vendor.

Apparently go-mod expects semver (vX.Y.Z) naming for tags/branches, but
kubernetes-1.13.2 is not in that format so for k8s.io/xxx packages
it gets replaced to v0.0.0-commit id every time we run go mod,
see: golang/go#27271

Go automatically detects ginkgo/gomega usage, and adds it to the
go.mod file, resulting in vendoring those pkgs, which may
be ok if we want to provide a built version of the e2e binary
as kubefed will be doing soon.
@mangelajo mangelajo mentioned this issue Jul 1, 2019
Merged
mangelajo added a commit to mangelajo/submariner that referenced this issue Jul 2, 2019
@mangelajo
Update to go mod and go 1.12.6, unvendor
176d30d 
This commit moves compilation into go mod, removing the vendored
sources. Go will automatically download and install modules
although you'll need to setup GO111MODULE=on in your env

Apparently go-mod expects semver (vX.Y.Z) naming for tags/branches, but
kubernetes-1.13.2 is not in that format so for k8s.io/xxx packages
it gets replaced to v0.0.0-commit id every time we run go mod,
see: golang/go#27271

Go automatically detects ginkgo/gomega usage, and adds it to the
go.mod file, resulting in vendoring those pkgs, which may
be ok if we want to provide a built version of the e2e binary
as kubefed will be doing soon.
mangelajo added a commit to mangelajo/submariner that referenced this issue Jul 2, 2019
@mangelajo
Update to go mod and go 1.12.6, unvendor
6b8cb84 
This commit moves compilation into go mod, removing the vendored
sources. Go will automatically download and install modules
although you'll need to setup GO111MODULE=on in your env

Apparently go-mod expects semver (vX.Y.Z) naming for tags/branches, but
kubernetes-1.13.2 is not in that format so for k8s.io/xxx packages
it gets replaced to v0.0.0-commit id every time we run go mod,
see: golang/go#27271

Go automatically detects ginkgo/gomega usage, and adds it to the
go.mod file, resulting in vendoring those pkgs, which may
be ok if we want to provide a built version of the e2e binary
as kubefed will be doing soon.
mangelajo added a commit to mangelajo/submariner that referenced this issue Jul 2, 2019
@mangelajo
Update to go mod and go 1.12.6, unvendor
71d4fcc 
This commit moves compilation into go mod, removing the vendored
sources. Go will automatically download and install modules
although you'll need to setup GO111MODULE=on in your env

Apparently go-mod expects semver (vX.Y.Z) naming for tags/branches, but
kubernetes-1.13.2 is not in that format so for k8s.io/xxx packages
it gets replaced to v0.0.0-commit id every time we run go mod,
see: golang/go#27271

Go automatically detects ginkgo/gomega usage, and adds it to the
go.mod file, resulting in vendoring those pkgs, which may
be ok if we want to provide a built version of the e2e binary
as kubefed will be doing soon.
mangelajo added a commit to mangelajo/submariner that referenced this issue Jul 2, 2019
@mangelajo
Update to go mod and go 1.12.6, unvendor
f8c92ec 
This commit moves compilation into go mod, removing the vendored
sources. Go will automatically download and install modules
although you'll need to setup GO111MODULE=on in your env

Apparently go-mod expects semver (vX.Y.Z) naming for tags/branches, but
kubernetes-1.13.2 is not in that format so for k8s.io/xxx packages
it gets replaced to v0.0.0-commit id every time we run go mod,
see: golang/go#27271

Go automatically detects ginkgo/gomega usage, and adds it to the
go.mod file, resulting in vendoring those pkgs, which may
be ok if we want to provide a built version of the e2e binary
as kubefed will be doing soon.
mangelajo added a commit to mangelajo/submariner that referenced this issue Jul 3, 2019
@mangelajo
Update to go mod and go 1.12.6, unvendor
472efdc 
This commit moves compilation into go mod, removing the vendored
sources. Go will automatically download and install modules
although you'll need to setup GO111MODULE=on in your env

Apparently go-mod expects semver (vX.Y.Z) naming for tags/branches, but
kubernetes-1.13.2 is not in that format so for k8s.io/xxx packages
it gets replaced to v0.0.0-commit id every time we run go mod,
see: golang/go#27271

Go automatically detects ginkgo/gomega usage, and adds it to the
go.mod file, resulting in vendoring those pkgs, which may
be ok if we want to provide a built version of the e2e binary
as kubefed will be doing soon.
mangelajo added a commit to mangelajo/submariner that referenced this issue Jul 3, 2019
@mangelajo
Update to go mod and go 1.12.6, unvendor
e69c971 
This commit moves compilation into go mod, removing the vendored
sources. Go will automatically download and install modules
although you'll need to setup GO111MODULE=on in your env

Apparently go-mod expects semver (vX.Y.Z) naming for tags/branches, but
kubernetes-1.13.2 is not in that format so for k8s.io/xxx packages
it gets replaced to v0.0.0-commit id every time we run go mod,
see: golang/go#27271

Go automatically detects ginkgo/gomega usage, and adds it to the
go.mod file, resulting in vendoring those pkgs, which may
be ok if we want to provide a built version of the e2e binary
as kubefed will be doing soon.
tpantelis pushed a commit to tpantelis/submariner that referenced this issue Jul 3, 2019
@mangelajo @tpantelis
Update to go mod and go 1.12.6, unvendor
b492dcd 
This commit moves compilation into go mod, removing the vendored
sources. Go will automatically download and install modules
although you'll need to setup GO111MODULE=on in your env

Apparently go-mod expects semver (vX.Y.Z) naming for tags/branches, but
kubernetes-1.13.2 is not in that format so for k8s.io/xxx packages
it gets replaced to v0.0.0-commit id every time we run go mod,
see: golang/go#27271

Go automatically detects ginkgo/gomega usage, and adds it to the
go.mod file, resulting in vendoring those pkgs, which may
be ok if we want to provide a built version of the e2e binary
as kubefed will be doing soon.
@golang golang locked and limited conversation to collaborators Sep 27, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Go1.12
Development

No branches or pull requests
5 participants
@FiloSottile @bcmills @aanm @gopherbot @thepudds