Skip to content
This repository has been archived by the owner on Sep 9, 2020. It is now read-only.

dep ensure ignores constraint in Gopkg.toml #1466

Closed
rsc opened this issue Dec 19, 2017 · 7 comments
Closed

dep ensure ignores constraint in Gopkg.toml #1466

rsc opened this issue Dec 19, 2017 · 7 comments

Comments

@rsc
Copy link

rsc commented Dec 19, 2017

I'm probably holding it wrong, so I apologize in advance for that, but I can't find documentation on how to hold it right.

I have a test repo rsc/dt1-main that imports rsc/dt1-a that imports rsc/dt1-b.
dt1-main's manifest says to use dt1-a with version = "1.0.1" (which I understand allows newer versions) and dt1-b with version "=1.0.0" (which I expected would not allow newer versions). dt1-a's manifest says to use dt1-b with version "1.0.0".

But dep ensure chooses dt1-b 1.1.0, which I'm trying to avoid because it is buggy.

I'm doing the wrong thing, to be sure. But what is the right thing? And what docs should I be reading? In particular I can't find any docs about the format of the version string.

Maybe most troubling, if I change dt1-main's Gopkg.toml to say to use dt1-b with version "=pizza", dep ensure still behaves the same way. It is like dep ensure is completely ignoring that stanza.

$ cd $GOPATH/src
$ git clone https://github.com/rsc/dt1-main 
Cloning into 'dt1-main'...
remote: Counting objects: 5, done.        
remote: Compressing objects: 100% (5/5), done.        
remote: Total 5 (delta 0), reused 5 (delta 0), pack-reused 0        
Unpacking objects:  20% (1/5)   
Unpacking objects:  40% (2/5)   
Unpacking objects:  80% (4/5)   
Unpacking objects: 100% (5/5), done.
$ cd dt1-main
$ ls
Gopkg.toml	main.go
$ cat Gopkg.toml
[[constraint]]
  name = "github.com/rsc/dt1-a"
  version = "1.0.1"

[[constraint]]
  name = "github.com/rsc/dt1-b"
  version = "=1.0.0"
$ cat vendor/github.com/rsc/dt1-a/Gopkg.toml
[[constraint]]
  name = "github.com/rsc/dt1-b"
  version = "1.0.0"
$ dep ensure
$ cat Gopkg.lock
# This file is autogenerated, do not edit; changes may be undone by the next 'dep ensure'.


[[projects]]
  name = "github.com/rsc/dt1-a"
  packages = ["A"]
  revision = "636131f45a73728f206994bc6309410bcc21431a"
  version = "v1.0.1"

[[projects]]
  name = "github.com/rsc/dt1-b"
  packages = ["B"]
  revision = "65635890162b8922da2bd3b00394aee578791ad6"
  version = "v1.1.0"

[solve-meta]
  analyzer-name = "dep"
  analyzer-version = 1
  inputs-digest = "b955301711cafb42cb1959507aa2210a7d13e8bef2b4dd487a4b939479b137d9"
  solver-name = "gps-cdcl"
  solver-version = 1
$ go build
$ ./dt1-main
panic: B.F

goroutine 1 [running]:
dt1-main/vendor/github.com/rsc/dt1-b/B.F()
	/tmp/src/dt1-main/vendor/github.com/rsc/dt1-b/B/b.go:3 +0x39
dt1-main/vendor/github.com/rsc/dt1-a/A.F()
	/tmp/src/dt1-main/vendor/github.com/rsc/dt1-a/A/a.go:6 +0x20
main.main()
	/tmp/src/dt1-main/main.go:5 +0x20
$ 
@ChrisHines
Copy link
Contributor

The way dep currently works, you have to use an [[override]] to constrain transitive dependencies. [[constraint]] sections only affect direct dependencies. I think the docs you are looking for are here: https://github.com/golang/dep/blob/master/docs/FAQ.md#how-do-i-constrain-a-transitive-dependencys-version.

@ChrisHines
Copy link
Contributor

@johanbrandhorst
Copy link
Member

I find this to be a very common misconception about how the Gopkg.toml file works. Could we add a warning about ignored constraints?

@carolynvs
Copy link
Collaborator

@johanbrandhorst Agreed! It's confusing as all get out, even for me sometimes. 😀 We are evaluating if we can fix that but for now I recommend subscribing to #302 which adds a warning when you have a constraint in your manifest that will be ignored.

@johanbrandhorst
Copy link
Member

That issue is exactly what I was looking for, thank you @carolynvs!

@sdboyer
Copy link
Member

sdboyer commented Dec 28, 2017

yeah, i think this is probably the single biggest gotcha we have right now. i'd left #302 for a long, long time thinking that we could get a contributor to take care of it. but that's proved unwise. i'm just going to take care of adding the warnings, before our next release.

@sdboyer
Copy link
Member

sdboyer commented Dec 29, 2017

also very relevant: #1124

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants