dep revision constraint doesn't appear to work
davecheney opened this issue · 8 comments
davecheney commented
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 commented
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 commented
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 commented
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 commented
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 commented
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 commented
@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 commented
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 commented
That's true, I forgot about Gopkg.lock. Thank you.