dep are you using (dep version)?% cd $GOPATH/src/github.com/golang/dep && git describe --tags
v0.3.1-66-gac1a162
dep command did you run?% grep -a2 apimach Gopkg.toml
[[constraint]]
name="k8s.io/apimachinery"
revision="917740426ad66ff818da4809990480bcc0786a77"
dep ensure -v
(22) ? attempt k8s.io/apimachinery with 26 pkgs; 4 versions to try
(23) try k8s.io/apimachinery@master
(23) ✓ select k8s.io/apimachinery@master w/42 pkgs
^ dep selected k8s.io/apimachinery@master, it should have selected k8s.io/apimachinery@917740426ad66ff818da4809990480bcc0786a77
heeeyooo! most probably, k8s.io/apimachinery is a transitive dependency, so your constraints don't affect it. we've had an issue open forever to warn about ineffectual constraints, #302, as it seemed like a good-ish task for someone new to take on. but this bites too many people for too long - i should maybe just bang out the fix.
Yup, I figured out I had to use [[override]] to get the result I wanted.
IMO this is very odd behaviour.
Transitive in this sense means "I couldn't find a direct path to this code
in your application"; however because of the design choices of
k8s.io/client-go project, it is mated at the hip to a specific revision of
k8s.io/apimachinery (yet they decline to version the later).
Why not just make Constraint do the right thing always -- constrain the set
of revisions of apimachinery that can go into the build to an exact
revision, rather than having Override which is for the odd case that
apimachinary is not a direct dependency on my project. It seems weird that
should I later import something from apimachinery (which may very well
happen), Constraint would start to work -- this is very hard to debug.
On Mon, Oct 2, 2017 at 6:13 AM, sam boyer notifications@github.com wrote:
heeeyooo! most probably, k8s.io/apimachinery is a transitive dependency, so
your constraints don't affect it
https://github.com/golang/dep/blob/master/docs/FAQ.md#why-is-dep-ignoring-a-version-constraint-in-the-manifest.
we've had an issue open forever to warn about ineffectual constraints,302 https://github.com/golang/dep/issues/302, as it seemed like a
good-ish task for someone new to take on. but this bites too many people
for too long - i should maybe just bang out the fix.1124 https://github.com/golang/dep/issues/1124 has a bunch of
discussion on allowing constraints to operate transitively. (not)
coincidentally, k8s is at the center of that one, too.—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/golang/dep/issues/1231#issuecomment-333448642, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcA2uvGhJlf7R0aH_tex6lfIi20TB8ks5soH8AgaJpZM4PqLPv
.
I think it's a bigger problem than a case of transitive dependency (if I understand it correctly).
Here, I am directly overriding aws-sdk-go to a lower version of 1.10.19 and dep seems to be ignoring it:
mve@mybox test $ egrep -v "^#|^$" Gopkg.toml
[[override]]
name = "github.com/aws/aws-sdk-go"
version = "1.10.19"
mve@mybox test $ dep ensure -update github.com/aws/aws-sdk-go
mve@mybox test $ dep status
PROJECT CONSTRAINT VERSION REVISION LATEST PKGS USED
github.com/aws/aws-sdk-go * (override) v1.12.7 7607418 7607418 27
github.com/go-ini/ini * v1.28.2 20b96f6 20b96f6 1
github.com/jmespath/go-jmespath * 0b12d6b 1
mve@mybox test $
mve@mybox test $ dep version
dep:
version : devel
build date :
git hash :
go version : go1.9
go compiler : gc
platform : darwin/amd64
mve@mybox test $ type dep
dep is hashed (/usr/local/bin/dep)
mve@mybox test $ ls -l /usr/local/bin/dep
lrwxr-xr-x 1 mve admin 27 Oct 4 15:33 /usr/local/bin/dep -> ../Cellar/dep/0.3.1/bin/dep
mve@mybox test $
It's a simple main.go test app:
```mve@mybox test $ ls -l
total 143888
-rw-r--r-- 1 mve staff 1220 Oct 10 08:50 Gopkg.lock
-rw-r--r-- 1 mve staff 608 Oct 9 10:04 Gopkg.toml
-rw-r--r-- 1 mve staff 1990 Oct 9 11:19 main.go
-rwxr-xr-x 1 mve staff 10032724 Oct 9 11:19 tst-aws-s3
drwxr-xr-x 3 mve staff 102 Oct 10 08:50 vendor
mve@mybox test $ cat main.go
package main
import (
"fmt"
"io"
"os"
"github.com/aws/aws-sdk-go/aws"
"github.com/aws/aws-sdk-go/aws/awserr"
"github.com/aws/aws-sdk-go/aws/session"
"github.com/aws/aws-sdk-go/service/s3"
"github.com/aws/aws-sdk-go/service/s3/s3manager"
)
...
...
```
Solution (as noted https://github.com/golang/dep/issues/1207#issuecomment-333625792) is to switch to revision override:
mve@mybox test $ egrep -v "^#|^$" Gopkg.toml
[[override]]
name = "github.com/aws/aws-sdk-go"
revision = "75d583c2afd3807d4d3f24b31b06feebb8849242"
mve@mybox test $ dep ensure -update github.com/aws/aws-sdk-go
Gopkg.lock is out of sync with Gopkg.toml or the project's imports. Run "dep ensure" to resync them first before running "dep ensure -update"
mve@mybox test $ dep ensure
mve@mybox test $ dep status
PROJECT CONSTRAINT VERSION REVISION LATEST PKGS USED
github.com/aws/aws-sdk-go 75d583c (override) 75d583c 27
github.com/go-ini/ini * v1.28.2 20b96f6 20b96f6 1
github.com/jmespath/go-jmespath * 0b12d6b 1
mve@mybox test $
I'm on my phone right now so I can't provide links, but what you're seeing with the version property there is implicit carets. This is explained in the semver section of the README.
On October 10, 2017 12:35:49 PM EDT, Vitaliy Mogilevskiy notifications@github.com wrote:
Solution (as noted
https://github.com/golang/dep/issues/1207#issuecomment-333625792) is to
switch torevisionoverride:mve@mybox test $ egrep -v "^#|^$" Gopkg.toml [[override]] name = "github.com/aws/aws-sdk-go" revision = "75d583c2afd3807d4d3f24b31b06feebb8849242" mve@mybox test $ dep ensure -update github.com/aws/aws-sdk-go Gopkg.lock is out of sync with Gopkg.toml or the project's imports. Run "dep ensure" to resync them first before running "dep ensure -update" mve@mybox test $ dep ensure mve@mybox test $ dep status PROJECT CONSTRAINT VERSION REVISION LATEST PKGS USED github.com/aws/aws-sdk-go 75d583c (override) 75d583c 27 github.com/go-ini/ini * v1.28.2 20b96f6 20b96f6 1 github.com/jmespath/go-jmespath * 0b12d6b 1 mve@mybox test $--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/golang/dep/issues/1231#issuecomment-335532887
@sdboyer I see, so to get it to pin at a certain version I would have to switch to version = "=1.10.19". Thank you -- that was a classic RTFM case on my part :) OTOH, = could have been a nicer default to alleviate these types of questions.
yes. but that's generally only ideal if you are certain your project cannot work with newer versions.
if you're just trying to make sure that version is that exact one for now, but expect you'll upgrade later, the workflow with less friction is generally the one where you don't use =, and trust Gopkg.lock to be sufficient for keeping it pinned. which will almost always be the case, as long as you always run dep ensure -update WITH explicit arguments.
I really need to write some good docs stories around this 😢
On October 14, 2017 7:10:37 PM EDT, Vitaliy Mogilevskiy notifications@github.com wrote:
@sdboyer I see, so to get it to pin at a certain version I would have
to switch toversion = "=1.10.19"--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/golang/dep/issues/1231#issuecomment-336673777
That's true, I forgot about Gopkg.lock. Thank you.
Most helpful comment
Yup, I figured out I had to use [[override]] to get the result I wanted.
IMO this is very odd behaviour.
Transitive in this sense means "I couldn't find a direct path to this code
in your application"; however because of the design choices of
k8s.io/client-go project, it is mated at the hip to a specific revision of
k8s.io/apimachinery (yet they decline to version the later).
Why not just make Constraint do the right thing always -- constrain the set
of revisions of apimachinery that can go into the build to an exact
revision, rather than having Override which is for the odd case that
apimachinary is not a direct dependency on my project. It seems weird that
should I later import something from apimachinery (which may very well
happen), Constraint would start to work -- this is very hard to debug.
On Mon, Oct 2, 2017 at 6:13 AM, sam boyer notifications@github.com wrote: