-
Notifications
You must be signed in to change notification settings - Fork 1k
Conversation
834e8e6
to
331c6fb
Compare
cmd/dep/base_importer.go
Outdated
} | ||
} | ||
|
||
// isVersion determines if the specified value is a tag (plain or semver). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
isTag
cmd/dep/base_importer.go
Outdated
return orderedProjects, nil | ||
} | ||
|
||
// importProject loads imported projects into the manifest and lock. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
importPackages loads imported packages
?
The importers are now only responsible for reading config files and feeding unvalidated lock and constraint hints into importPackages.
* Don’t throw away a locked version match due to a conflicting constraint unless there is another match that _does_ match * Ignore pinned constraints * Ignore conflicting constraints
github.com/carolynvs/deptest-importers contains the entire matrix of testdata needed by the importers
* The setup and validation for all the importer testcases are the same, they just need to handle calling the importer properly. * Flag importer tests to run in parallel now that they've been cleaned up.
fc84b3e
to
1407196
Compare
This is finally ready for review! 🎉 I would really love to get this in by the end of the week. So if I don't hear anyone screaming at me to not merge by then.... 😇 |
cmd/dep/base_importer.go
Outdated
case gps.IsRevision: | ||
return true | ||
case gps.IsVersion: | ||
return true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit:
case gps.IsRevision, gps.IsVersion:
return true
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! I knew there was a better way of doing that! ❤️
cmd/dep/base_importer.go
Outdated
return false | ||
} | ||
|
||
func (i *baseImporter) testConstraint(c gps.Constraint, v gps.Version) bool { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Comment?
I can't tell if the new bolt tests are flaky or if I managed to break them somehow?
|
Seems flaky, I'm working on reproducing it. I'm hoping it's just some clock funkiness. I restarted the failed job. |
The closure created by t.Run wasn't copying the testcase value, so the test was being run on the wrong values.
When a lock hint is empty, nothing should be added to the lock
Turns out that #1130 was already fixed by this PR. Go me. 😉 So I just added a test to verify the correct behavior. I also realized that my parallel tests weren't working as I had thought. I'm now making local copies of the testcase variables so that they are properly included in the subtest closure. |
What does this do / why do we need it?
Each importer has slightly different behavior, and currently anyone who wants to contribute an importer needs to have some pretty significant dep knowledge (or I need to really be on my game during the code review!).
This makes it so that importers are only responsible for discovering and parsing config files. They then provide 3 pieces of information to a common function which handles the rest of the import logic: import path, text which possibly contains lock info, text which possibly contains constraint info. (Some tools know about ignores and are still responsible for adding those too).
The new base importer handles
dep ensure
, will require turning off the "constraint guessing".I have also completely redone the tests against a single repository that contains all the testdata necessary for the import scenarios (github.com/carolynvs/deptest-importers). The tests now run in parallel too! 🎉
Apologies for the big PR! Unfortunately, we've gotten to where we are now thanks to piecemeal, incremental implementations and I want to make sure this works as a whole before anything lands in master.
What should your reviewer look out for in this PR?
I'd like extra eyes on the import rules (see the inline doc on
baseImporter.importProjects
for the rules).Do you need help or clarification on anything?
Nope
Which issue(s) does this PR fix?
Fixes #939
Notes:
baseImporter.importProjects
is ripe for concurrency. I didn't want to tackle that on top of everything else though, as there were enough big changes in that same area in this PR. But it's on my radar after this PR merges and looks stable.