You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 9, 2020. It is now read-only.
I am working on setting up a table of init test cases. Below are the descriptions of the first three cases, but I am getting results other than I expect. The table shows my expectation, and afterwards are what I am getting:
Two remote repos: repo A used in code, and repo A depends on repo B
Remote repo A: has version 2.0.0 and later commit a0196
Remote repo B: has versions 0.8.0, 0.8.1, and 1.0.0 and later commit 3f4c3
Case
Gopath
Vendor
Exp Manifest
Exp Lock
Case 1
-
-
-
A 2.0.0, B 1.0.0
Case 2
A a0196
-
A a0196
A a0196, B 1.0.0
Case 3
B 0.8.0
-
B 0.8.0
A 2.0.0, B 0.8.0
I am getting the correct answer in case 1
In case 2, I am getting the correct manifest, but the later B 3f4c3 revision in the lock
In case 3, I am getting no manifest, and B 1.0.0 in the lock (note this is a consistent sol'n, just not the one I'd expect)
Are the above expectations wrong, or are these bugs? I'd think the lock choices would be the latest tagged remote version when there is nothing in Gopath or Vendor, and when something is, it would take precedence and the manifest would modify to reflect that pecedence.
The text was updated successfully, but these errors were encountered:
tro3
changed the title
Setting up init test table - don't understand results
Setting up init test table - don't understand results
Mar 10, 2017
First, I should note that we're planning changes to how init works. ensure, too (and remove) is going away. #277
Case 3 is expected, albeit a bit confusing. The init algorithm works by recursively traversing import paths in GOPATH, and picking up versions therein. The key thing there is recursive - when A isn't present in GOPATH, then the algorithm can't recurse through it to discover that B is also needed. So case 3 ends up providing the same inputs to the solver as case 1 (namely, an empty lock).
Case 2 is weirder. Honestly not sure why that's happening. Without B on disk, it should just leave it to the solver to pick a version, resulting in 1.0.0 at ff2948a2ac8f538c4ecd55962e919d1e13e74baf. Seems worth investigating that further, we may have a bug.
Okay. With the changes coming, maybe it makes more sense to just work on the table for now, rather than coding the tests just yet. I'll close this issue and the previous two #283, #284, as all would get caught by the proper test suite. Agreed?
I am working on setting up a table of
init
test cases. Below are the descriptions of the first three cases, but I am getting results other than I expect. The table shows my expectation, and afterwards are what I am getting:Two remote repos: repo A used in code, and repo A depends on repo B
Remote repo A: has version 2.0.0 and later commit a0196
Remote repo B: has versions 0.8.0, 0.8.1, and 1.0.0 and later commit 3f4c3
Are the above expectations wrong, or are these bugs? I'd think the lock choices would be the latest tagged remote version when there is nothing in Gopath or Vendor, and when something is, it would take precedence and the manifest would modify to reflect that pecedence.
The text was updated successfully, but these errors were encountered: