dep revision constraint doesn't appear to work

[davecheney]

What version of dep are you using (dep version)?

% cd $GOPATH/src/github.com/golang/dep && git describe --tags
v0.3.1-66-gac1a162

What dep command did you run?

% grep -a2 apimach Gopkg.toml 

[[constraint]]
  name="k8s.io/apimachinery"
  revision="917740426ad66ff818da4809990480bcc0786a77"

dep ensure -v

What did you expect to see?

What did you see instead?

(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

[sdboyer]

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.

#1124 has a bunch of discussion on allowing constraints to operate transitively. (not) coincidentally, k8s is at the center of that one, too.

[davecheney]

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 ***@***.***> 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 <#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 <#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 <#1231 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAcA2uvGhJlf7R0aH_tex6lfIi20TB8ks5soH8AgaJpZM4PqLPv> .

[vmogilev]

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:

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"
)
...
...

[vmogilev]

Solution (as noted #1207 (comment)) 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 $

[sdboyer]

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 ***@***.***> wrote: Solution (as noted #1207 (comment)) is to switch to `revision` override: ``` ***@***.*** test $ egrep -v "^#|^$" Gopkg.toml [[override]] name = "github.com/aws/aws-sdk-go" revision = "75d583c2afd3807d4d3f24b31b06feebb8849242" ***@***.*** 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" ***@***.*** test $ dep ensure ***@***.*** 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 ***@***.*** test $ ``` -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #1231 (comment)

[vmogilev]

@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.

[sdboyer]

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 ***@***.***> wrote: @sdboyer I see, so to get it to pin at a certain version I would have to switch to `version = "=1.10.19"` -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #1231 (comment)

[vmogilev]

That's true, I forgot about Gopkg.lock. Thank you.