dep revision constraint doesn't appear to work

Created on 2 Oct 2017  Â·  8Comments  Â·  Source: golang/dep

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

help wanted

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:

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
.

All 8 comments

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.

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 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 $

--
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 to version = "=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.

Was this page helpful?
0 / 5 - 0 ratings