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

Interpret strings as branches > semver constraints #715

Merged
merged 2 commits into from
Jul 7, 2017

Conversation

carolynvs
Copy link
Collaborator

@carolynvs carolynvs commented Jun 3, 2017

Fixes #710. 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 #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 carolynvs changed the title Interpret strings as branches > semver constraints WIP: Interpret strings as branches > semver constraints Jun 3, 2017
@carolynvs
Copy link
Collaborator Author

carolynvs commented Jun 3, 2017

This isn't quite ready yet because doesn't work with the testdata from https://gist.github.com/ellotheth/e96f8f2c5fdd1b9e09e183970cfb276b.

  • Feedback doesn't look right when the constraint is a branch.
  • My test repo isn't quite right, getting a subpackage error for mikespook/gearman-go which is causing the wrong rev to be locked. Nevermind, this is a problem with that repo, so I've removed it from the testcase.
$ dep init -v
Importing configuration from glide. These are only initial constraints, and are further refined during the solve process.
Detected glide configuration files...
  Loading /tmp/src/foo/glide.yaml
  Loading /tmp/src/foo/glide.lock
Converting from glide.yaml and glide.lock...
  Using ^1.1.0 as initial constraint for imported dep github.com/DataDog/datadog-go
  Trying 1.1.0 (0ddda6b) as initial lock for imported dep github.com/DataDog/datadog-go
  Using b79fee2 as initial hint for imported dep github.com/mikespook/gearman-go
  Using 29cc868 as initial hint for imported dep gopkg.in/mgo.v2
Searching GOPATH for projects...
Root project is "foo"
 1 transitively valid internal packages
 3 external packages imported from 3 projects
(0)   ✓ select (root)
(1)	? attempt github.com/DataDog/datadog-go with 1 pkgs; at least 1 versions to try
(1)	    try github.com/DataDog/datadog-go@1.1.0
(1)	✓ select github.com/DataDog/datadog-go@1.1.0 w/1 pkgs
(2)	? attempt github.com/mikespook/gearman-go with 1 pkgs; at least 1 versions to try
(2)	    try github.com/mikespook/gearman-go@b79fee29655dcdce7ba4a738f8388f9862b6779e
(3)	✗   github.com/mikespook/gearman-go at b79fee29655dcdce7ba4a738f8388f9862b6779e has problem subpkg(s):
(3)	  	github.com/mikespook/gearman-go/worker has err (*pkgtree.LocalImportsError); required by (root).
(2)	    try github.com/mikespook/gearman-go@0.1.3
(2)	✓ select github.com/mikespook/gearman-go@0.1.3 w/2 pkgs
(3)	? attempt gopkg.in/mgo.v2 with 1 pkgs; at least 1 versions to try
(3)	    try gopkg.in/mgo.v2@29cc868a5ca65f401ff318143f9408d02f4799cc
(3)	✓ select gopkg.in/mgo.v2@29cc868a5ca65f401ff318143f9408d02f4799cc w/1 pkgs
  ✓ found solution with 4 packages from 3 projects

This was referenced Jun 11, 2017
@carolynvs carolynvs changed the title WIP: Interpret strings as branches > semver constraints Interpret strings as branches > semver constraints Jun 11, 2017
@carolynvs carolynvs force-pushed the detect-branch-vs-tag branch 3 times, most recently from 74a0a26 to 62b206f Compare June 11, 2017 18:08
@carolynvs
Copy link
Collaborator Author

@sdboyer This is ready for review, though beware that it is currently pulling into two other PRs, #729 and #744. I recommend limiting the github diff to just the last commit so you don't see the changes from those other PRs.

I needed another test case for deduceConstraint where a branch name could be interpreted as a semver. I added that to my deptest fork but let me know if it belongs elsewhere.

@carolynvs
Copy link
Collaborator Author

Rebased now that the other PRs are now merged.

@carolynvs
Copy link
Collaborator Author

@sdboyer @darkowlzz @ibrasho Bumping for great glory. 🇺🇸 🎇

Copy link
Collaborator

@ibrasho ibrasho left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Naming nits.

// project based on the locked revision and the constraint from the manifest.
// First try matching the revision to a version, then try the constraint from the
// manifest, then finally the revision.
func lookupVersionForLockedProject(pi gps.ProjectIdentifier, c gps.Constraint, rev gps.Revision, sm gps.SourceManager) (version gps.Version, warning error) {
Copy link
Collaborator

@ibrasho ibrasho Jul 3, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the benefit of named return values here?

Also, naming the error warning seems a bit misleading.

For lookupVersionForLockedProject, it's an error that prevents returning the expected results. Consumers cannot rely on the version returned since it will be nil.

A consumer can call this value warning if it doesn't depend on getting a valid gps.Version value. But I would only call it warning here if consumers could, somehow, use the returned value if they didn't care about the warning.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would only call it warning here if consumers could, somehow, use the returned value if they didn't care about the warning.

Thanks! That is a good way of thinking about err/warn, very helpful.

warn := errors.Wrapf(err, "Unable to lookup the version represented by %s in %s. Falling back to locking the revision only.", pkg.Rev, pi.ProjectRoot)
g.logger.Printf(warn.Error())
version = revision
version, warning := lookupVersionForLockedProject(pi, nil, revision, g.sm)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd even call this variable err since the comment below explains why it was logged and ignored (same thing in glide importer).

@carolynvs
Copy link
Collaborator Author

I've renamed from warning -> err and removed the named return values.

@darkowlzz
Copy link
Collaborator

darkowlzz commented Jul 5, 2017

I went through it. LGTM 👍
cmd/dep/testdata/godep/expected_import_output.txt should have been changed too right? Refer: https://github.com/golang/dep/pull/742/files#r121284440

Just wondering why were the files renamed?
cmd/dep/testdata/glide/glide.lock → cmd/dep/testdata/glide/glide0.lock, etc

Copy link
Collaborator

@ibrasho ibrasho left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. 👍

@carolynvs
Copy link
Collaborator Author

Just wondering why were the files renamed?

I added a second testdata file, e.g. glide1.lock, then didn't need it later on, but the filename change persisted after I squashed all my commits. Fixing.... 😊

@carolynvs
Copy link
Collaborator Author

  • @darkowlzz reminded me that I promised that this PR would also fix the godep importer.
  • Improved which version is picked when a rev has multiple tags. When the manifest has a semver constraint, dep uses the constraint to filter the tagged versions. Since this only impacts the preferred version in the lock, the solver may still pick something different, but at least dep no longer suggests (and prints) something that is impossible. This stems from case in github.com/sdboyer/deptest, where rev ff2948a is tagged with both v0.8.0 and v1.0.0.

wantV := "v1.0.0"
gotV := v.String()
if gotV != wantV {
t.Fatalf("Expected '%s', got '%s'", wantV, gotV)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about adding a little context to the failure message, like we try to do everywhere and in alignment with the existing test in the file?
Same for the tests below 🙂

@googlebot
Copy link
Collaborator

So there's good news and bad news.

👍 The good news is that everyone that needs to sign a CLA (the pull request submitter and all commit authors) have done so. Everything is all good there.

😕 The bad news is that it appears that one or more commits were authored by someone other than the pull request submitter. We need to confirm that they're okay with their commits being contributed to this project. Please have them confirm that here in the pull request.

Note to project maintainer: This is a terminal state, meaning the cla/google commit status will not change from this state. It's up to you to confirm consent of the commit author(s) and merge this pull request when appropriate.

@googlebot googlebot added cla: no and removed cla: yes labels Jul 6, 2017
@carolynvs
Copy link
Collaborator Author

@darkowlzz Thanks for calling me out on that! 😀 I've added context to the test failure messages and squashed.

@carolynvs carolynvs force-pushed the detect-branch-vs-tag branch 2 times, most recently from 1b181b9 to b77f0c1 Compare July 6, 2017 14:24
@googlebot
Copy link
Collaborator

CLAs look good, thanks!

@googlebot googlebot added cla: yes and removed cla: no labels Jul 6, 2017
@carolynvs
Copy link
Collaborator Author

Derp, my rebase went awry. All fixed (hopefully). 🤞

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.
When selecting a preferred version for a lock (before solve)
if the constraint is a semver range, ensure the version
selected is compatible.
@sdboyer
Copy link
Member

sdboyer commented Jul 7, 2017

This seems good to me - can merge once we deal with those conflicts 😄

@carolynvs
Copy link
Collaborator Author

I've fixed the merge conflict.

@darkowlzz darkowlzz merged commit ddf5680 into golang:master Jul 7, 2017
@carolynvs carolynvs deleted the detect-branch-vs-tag branch October 6, 2017 15:43
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants