This repository has been archived by the owner on Sep 9, 2020. It is now read-only.
Detect constraint type when converting from glide #710
Assignees
Labels
Comments
|
I've got this, hoping to work on it this weekend. |
carolynvs
added a commit
to carolynvs/dep
that referenced
this issue
Jun 11, 2017
When a user supplied string in an imported config file, or specified to dep ensure, can be interpreted multiple ways, prefer the branch over a semver constraint. In golang#710, glide.yaml specified v2 for https://github.com/go-mgo/mgo. When we assume that is a semver constraint, solve fails because the hinted revision in the lock (a commit on the v2 branch) doesn't satisfy the assumed constraint of ^2.0.0. The new preferred match order for the user string is: * revision * branch * semver constraint * tag I am giving preference of a semver constraint over a tag so that a bare version, 1.0.0, is interpreted more loosely with an implied caret, ^1.0.0, instead of the stricter exact match.
carolynvs
added a commit
to carolynvs/dep
that referenced
this issue
Jun 11, 2017
When a user supplied string in an imported config file, or specified to dep ensure, can be interpreted multiple ways, prefer the branch over a semver constraint. In golang#710, glide.yaml specified v2 for https://github.com/go-mgo/mgo. When we assume that is a semver constraint, solve fails because the hinted revision in the lock (a commit on the v2 branch) doesn't satisfy the assumed constraint of ^2.0.0. The new preferred match order for the user string is: * revision * branch * semver constraint * tag I am giving preference of a semver constraint over a tag so that a bare version, 1.0.0, is interpreted more loosely with an implied caret, ^1.0.0, instead of the stricter exact match.
carolynvs
added a commit
to carolynvs/dep
that referenced
this issue
Jun 11, 2017
When a user supplied string in an imported config file, or specified to dep ensure, can be interpreted multiple ways, prefer the branch over a semver constraint. In golang#710, glide.yaml specified v2 for https://github.com/go-mgo/mgo. When we assume that is a semver constraint, solve fails because the hinted revision in the lock (a commit on the v2 branch) doesn't satisfy the assumed constraint of ^2.0.0. The new preferred match order for the user string is: * revision * branch * semver constraint * tag I am giving preference of a semver constraint over a tag so that a bare version, 1.0.0, is interpreted more loosely with an implied caret, ^1.0.0, instead of the stricter exact match.
carolynvs
added a commit
to carolynvs/dep
that referenced
this issue
Jun 11, 2017
When a user supplied string in an imported config file, or specified to dep ensure, can be interpreted multiple ways, prefer the branch over a semver constraint. In golang#710, glide.yaml specified v2 for https://github.com/go-mgo/mgo. When we assume that is a semver constraint, solve fails because the hinted revision in the lock (a commit on the v2 branch) doesn't satisfy the assumed constraint of ^2.0.0. The new preferred match order for the user string is: * revision * branch * semver constraint * tag I am giving preference of a semver constraint over a tag so that a bare version, 1.0.0, is interpreted more loosely with an implied caret, ^1.0.0, instead of the stricter exact match.
carolynvs
added a commit
to carolynvs/dep
that referenced
this issue
Jun 14, 2017
When a user supplied string in an imported config file, or specified to dep ensure, can be interpreted multiple ways, prefer the branch over a semver constraint. In golang#710, glide.yaml specified v2 for https://github.com/go-mgo/mgo. When we assume that is a semver constraint, solve fails because the hinted revision in the lock (a commit on the v2 branch) doesn't satisfy the assumed constraint of ^2.0.0. The new preferred match order for the user string is: * revision * branch * semver constraint * tag I am giving preference of a semver constraint over a tag so that a bare version, 1.0.0, is interpreted more loosely with an implied caret, ^1.0.0, instead of the stricter exact match.
carolynvs
added a commit
to carolynvs/dep
that referenced
this issue
Jul 6, 2017
When a user supplied string in an imported config file, or specified to dep ensure, can be interpreted multiple ways, prefer the branch over a semver constraint. In golang#710, glide.yaml specified v2 for https://github.com/go-mgo/mgo. When we assume that is a semver constraint, solve fails because the hinted revision in the lock (a commit on the v2 branch) doesn't satisfy the assumed constraint of ^2.0.0. The new preferred match order for the user string is: * revision * branch * semver constraint * tag I am giving preference of a semver constraint over a tag so that a bare version, 1.0.0, is interpreted more loosely with an implied caret, ^1.0.0, instead of the stricter exact match.
carolynvs
added a commit
to carolynvs/dep
that referenced
this issue
Jul 6, 2017
When a user supplied string in an imported config file, or specified to dep ensure, can be interpreted multiple ways, prefer the branch over a semver constraint. In golang#710, glide.yaml specified v2 for https://github.com/go-mgo/mgo. When we assume that is a semver constraint, solve fails because the hinted revision in the lock (a commit on the v2 branch) doesn't satisfy the assumed constraint of ^2.0.0. The new preferred match order for the user string is: * revision * branch * semver constraint * tag I am giving preference of a semver constraint over a tag so that a bare version, 1.0.0, is interpreted more loosely with an implied caret, ^1.0.0, instead of the stricter exact match.
carolynvs
added a commit
to carolynvs/dep
that referenced
this issue
Jul 6, 2017
When a user supplied string in an imported config file, or specified to dep ensure, can be interpreted multiple ways, prefer the branch over a semver constraint. In golang#710, glide.yaml specified v2 for https://github.com/go-mgo/mgo. When we assume that is a semver constraint, solve fails because the hinted revision in the lock (a commit on the v2 branch) doesn't satisfy the assumed constraint of ^2.0.0. The new preferred match order for the user string is: * revision * branch * semver constraint * tag I am giving preference of a semver constraint over a tag so that a bare version, 1.0.0, is interpreted more loosely with an implied caret, ^1.0.0, instead of the stricter exact match.
carolynvs
added a commit
to carolynvs/dep
that referenced
this issue
Jul 7, 2017
When a user supplied string in an imported config file, or specified to dep ensure, can be interpreted multiple ways, prefer the branch over a semver constraint. In golang#710, glide.yaml specified v2 for https://github.com/go-mgo/mgo. When we assume that is a semver constraint, solve fails because the hinted revision in the lock (a commit on the v2 branch) doesn't satisfy the assumed constraint of ^2.0.0. The new preferred match order for the user string is: * revision * branch * semver constraint * tag I am giving preference of a semver constraint over a tag so that a bare version, 1.0.0, is interpreted more loosely with an implied caret, ^1.0.0, instead of the stricter exact match.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
As discussed in #705 (comment), we need to do more work to figure out the right constraint type when looking at a string from glide. (Also relevant: giant discussion in Masterminds/glide#391)
The text was updated successfully, but these errors were encountered: